Re: [Openvpn-devel] [DEVELOPER REQUESTED] Repackage TAP-Win32

[Karl O. Pinc]

On 02/18/2012 06:04:48 PM, David Sommerseth wrote:

> Right now, debating tarball/zipball formats is a bit premature.  
> There
> are 8 challenging steps to solve before this.  Even though Windows
> doesn't support tarballs natively, LGPL tools like 7-Zip exists which
> will make that job easier.  And those needing to extract these pieces
> are
> not necessarily end-users, so we should expect people to know how to
> solve these things.
> 
> But for now, I'd like to see more focus on the steps before the
> packaging
> method.  We first need to have something to package.

Makes sense.

Regardless...

You might try my old patch that produces a tarball of MS binaries,
found here:

http://article.gmane.org/gmane.network.openvpn.devel/2578

It never got applied, partly because it needed supporting documentation
and the accompanying patch to update the website failed to apply
by the time anybody got around to looking at the patch. because
by then the website was reorganized.  Even if it does apply, it should
have supporting documentation before being accepted into the
tree.  I can't say if it's easier to poke about the old thread
to come up with appropriate documentation or to start from
scratch.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [DEVELOPER REQUESTED] Repackage TAP-Win32

[Karl O. Pinc]

On 02/18/2012 04:53:50 PM, Scott Zeid wrote:
> On Feb 18, 2012 9:05 AM, "Alon Bar-Lev"  
> wrote:
> > 9. Output of build system would be [at least] (msi, tarball) for
> > (win32, win64). Why tarball? To enable people to fetch files 
> without
> > hacking the msi (example: cross compile).
> 
> It should probably be a zip file since Windows doesn't support
> tarballs out
> of the box.

I'm not a MS guy, but that argument does not carry a whole lot
of weight since MS Windows does not support NSIS, or any other
sort of installer-crafter, out of the box either; and people should
be using an installer to install, not archived binaries
in whatever format.  It almost makes sense to make it harder
for the casual MS user to try to install using the raw
binaries.

Bikeshed argument flag!  In the end, it does not matter.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [DEVELOPER REQUESTED] Repackage TAP-Win32

[Karl O. Pinc]

On 02/18/2012 09:05:16 AM, Alon Bar-Lev wrote:
> Hello,
> 
> We have a go to rewrite the OpenvPN build system.

> 9. Output of build system would be [at least] (msi, tarball) for
> (win32, win64). Why tarball? To enable people to fetch files without
> hacking the msi (example: cross compile).

I'd like to second the motion to produce a MS tarball.  People
who want only to produce a custom OpenVPN installer, such
as the recent thread here regarding packaging OpenVPN
in conjunction with an SSL obfuscation proxy, should
not also have to go to the trouble to produce OpenVPN
binaries.  People should instead be able to rely on
the OpenVPN project for high-quality prebuilt
binaries suitable for repackaging into a customized
installer.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Problem with alloc_buf_gc function

[Karl O. Pinc]

On 12/29/2011 01:29:00 PM, Gert Doering wrote:

> Now I wouldn't know how to enable ip forwarding on Windows, and I
> wouldn't
> even think of running an OpenVPN server on Windows, but supposedly it
> can
> be done.  Let someone else chime in and answer that...

Perhaps on the openvpn-users list instead of on the developer list?



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Problem with alloc_buf_gc function

[Karl O. Pinc]

On 12/29/2011 08:24:54 AM, Gert Doering wrote:

> Linux needs to know that it is to be a router:
> 
>  # echo 1 >/proc/sys/net/ipv4/ip_forward

See /etc/sysctl.conf (man sysctl.conf) to set
forwarding at boot.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Debian master branch build?

[Karl O. Pinc]

On 12/17/2011 02:47:39 PM, Praetorian wrote:
> A few weeks/months ago in an IRC meeting I asked about a debian build
> for the master branch.  I recently installed the
> openvpn-2.x-master-20111202-wo-startup-test-install.exe on my vista
> laptop (which installed fine btw).  Is there a debian build coming
> that I could install to test all the new ipv6 functions in the 
> updated
> windows master branch installer? 

Is openvpn doing debian builds?  Sounds like a debian question.

Debian's irc bot has useful factoids for getting newer
software for Debian stable.  See:

http://wiki.debian.org/IRC/DpkgBot
http://ircbots.debian.net/factoid.php?key=backport
http://ircbots.debian.net/factoid.php?key=backports.debian.org
http://ircbots.debian.net/factoid.php?key=simple+sid+backport
http://ircbots.debian.net/search.php?q=uupdate=key

(Or, more generally, http://wiki.debian.org/DebianSoftware)

Or ask for help in #debian on irc.freenode.net.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] OemWin2k.inf specify network adapter name

[Karl O. Pinc]

On 06/03/2011 12:35:28 PM, Gert Doering wrote:
> Hi,
> 
> On Fri, Jun 03, 2011 at 07:14:39PM +0200, David Sommerseth wrote:
> > Pure feature wise, this really sounds like a reasonable thing to
> change.
> 
> ACK.  I like the idea.
> 
> But I have no idea whether this can be done, and if yes, how.

As long as you're taking comments from the clueless I'll chime in.
It sounds like one of those things that can be changed in
the registry which means to me it's something that the installer
should do.  But then I'm clueless when it comes to MS Windows
so this is just a guess. 




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] minimalistic OpenVPN

[Karl O. Pinc]

On 06/02/2011 10:46:00 AM, Mr Dash Four wrote:
> Is it possible to build a minimalistic version of OpenVPN to be used
> on 
> portables?
> 
> As part of in-house project I would like to be able to compile, build 
> install and use OpenVPN on HTC (Desire). I already have the modified
> OS 
> and the toolchain is already built and sufficiently tested, though I
> am 
> not certain as to whether building and using OpenVPN in such
> environment 
> is possible? Has this been attempted before?

OpenVPN runs under OpenWRT, which is designed for minimal devices.
I suppose it depends on how minimal.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] Change the default --tmp-dir path to a more suitable path

[Karl O. Pinc]

On 04/07/2011 07:51:55 AM, David Sommerseth wrote:
> [resend copy to openvpn-devel list as well]

> I checked for the $TMPDIR variable on CentOS 5.5, Fedora 14 and 
> Gentoo
> installations.  And $TMPDIR didn't show up at all, hence I thought
> this was
> not a really useful option.  However, I see from the wikipage that
> this is
> supposed to be part of SuS.  But it seems not to be respected in 
> Linux
> at
> least. 

FYI After poking about the man pages of various Un*xs I find:

login(1) does not have to set $TMPDIR, although the whole
login process can be configured to do so there's no 
requirement that $TMPDIR exist.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] OpenVPN documentation (man page) review

[Karl O. Pinc]

On 01/12/2011 02:48:29 PM, Jan Just Keijser wrote:

> As for the document format: if we want users to contribute then we 
> should not opt for a too-difficult format that users would have to
> learn 
> before being able to contribute. Docbook and/or texinfo are nice for 
> Linux users but you'd scare away most Windows/Mac users.
> What about plain simple OpenDoc (odf) ?

If you say so.  (It's not as if they haven't seen html,
which is superficially similar to docbook/xml,
or haven't they?)  But they could install and use lyx
and get a full-gui experience.  They'll have to install
something anyway if they want to use odf.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] OpenVPN documentation (man page) review

[Karl O. Pinc]

On 01/12/2011 02:40:00 AM, Matthias Andree wrote:
> Am 11.01.2011 12:20, schrieb David Sommerseth:
> > 
> > Hi folks!
> > 
> > This is a little cry for help from us playing with the OpenVPN 
> code.
> > 
> > We have a quite good man page today with a lot of information.  But
> > maintaining it and to make sure it is up-to-date with all the
> features
> > OpenVPN supports is often not high up on the priority list. 

Don't accept a patch unless the documentation is also patched?

 In
> > addition, the current format (one single file, in pure man page
> format)
> > is getting harder and harder to maintain as well.
> > 
> > So, we're hoping some people with some English skills is interested
> to
> > help out improving this situation.  What we immediately would like
> to
> > see is something along these lines:
> > 
> > * Move the man page to a better format than the pure man page
> format.
> >   Are there some good tools/formats like ascii2man or DocBookXML
> which
> >   could help easing the maintenance of our documentation?
> 
> Docbook XML for sure is a lot more verbose than asciidoc or roff.  I
> would tend
> to avoid Docbook, the toolchains are lacking a bit -- still :-(
> although xmlto +
> fop can yield reasonable PDF results.

This is a matter of taste.  I'd turn that on it's head and say
that Docbook is a lot more clear than roff.  How hard is stuff
like:

Overview
...

With an editor like emacs or lyx it's not even much more typing 
and you get built-in validation, etc.

I'm not sure I understand the tool criticism.  There's pdf and
html and all the other basic outputs.  You can use the
xinclude mechanism  to produce different documents from 
components broken into files.  So there can be a man page,
a reference book, a "pocket reference" with just a table
of arguments, etc, some content of which is shared and
some of which is unique to each document.  If you 
like you've all of xml and xslt
and so forth to manipulate the documents dynamically allowing
you to, say, suck an example configuration straight out of
the documentation into a text file to be distributed in
an examples directory to be installed with openvpn.
This way you don't maintain the same example in two places.

> 
> However, we should make sure that there still is something that works
> with "man".

Docbook should do man.  I've never actually done it but
here's a whole series of tags that 
support all the man-like formatting at the top of the man page
what with marking each argument etc.
Frankly, that's where you'll see the ugly verbosity.  Plain old
paragraphs and so forth are plainless.  But once the top of the
man page is done once you pretty much don't have to make changes
or if you do then you've an example to work from.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Can *plugin* kill specific ovpn tunnel?...

[Karl O. Pinc]

On 12/14/2010 04:22:53 PM, Vineet Kumar wrote:
> Sorry pl. explain the "intermediary" part. Is that supposed to solve
> the single telnet server accepting multiple *concurrent* client
> sessions?

Yes.  The multiple concurrent client sessions talk to a single 
telnet server via an intermediary.  The intermediary serializes
the requests made by the multiple concurrent sessions and feeds
the resulting stream to the single telnet session.

A simpleminded way to do this might be to dump the requests
into files in a directory that's monitored by incron, which
then feeds the commands to, say, socat or nc (netcat).
(Incron is a nice intermediary because it isolates the
requests -- they can be monitored for correctness etc.)
I've no idea if this is the right approach for your application.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] PATCH: floating-tls

[Karl O. Pinc]

On 12/02/2010 11:56:56 AM, Samuli Seppänen wrote:
> Hi Blaise,
> 
> Actually we discussed the floating-tls patch in last community
> meeting:
> 
> 
> 

The discussion ends with deciding that the feature be
"opt-in", I presume via a compile time option.
Why isn't it "opt-in" if enabled with a runtime command line
flag?  If you don't use the flag why should the
resulting session be any less secure?

I have no problem having to enable a compile time
flag for new feature testing, and then having
the flag default to "on" in a later release.
Is that what we're taking about here?


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] PATCH: floating-tls

[Karl O. Pinc]

On 12/02/2010 11:44:27 AM, Blaise Gassend wrote:
> Hi,
> 
> Didn't hear back from anybody. Is there really no interest at all in
> adding floating TLS?

Sounds like a nice feature to me, but I don't know enough
to ack the code.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Intelligent OpenVPN service?

[Karl O. Pinc]

On 10/18/2010 02:14:19 PM, Jason Haar wrote:
>  On 10/19/2010 07:43 AM, Davide Brini wrote:
> > Sorry for the silly question, but how do you expect the OpenVPN 
> link
> to be
> > established if the computer "does not already have a connection"?
> >
> > What do you mean with the above statement?
> I think he means: if the machine is on the corporate network, then
> don't
> kick off an openvpn connection to the corporate network
> 
> We did that here using firewall trickery. We block access to the
> openvpn
> server ports from the corporate network - that way openvpn can remain
> permanently running on all clients, and it will only work when 
> clients
> connect from non-corporate networks.
> 
> It's a kludge (hard to scale when you have dozens of corporate
> Internet
> address ranges) - what's really needed is a "--pre-connection" option
> -
> so that we can run scripts before the openvpn service even starts.
> Then
> the "pre" script could explicitly check if the corporate network is
> available (eg attempt to download a HTTPS page from an exclusively
> internal server) and error if it is - causing openvpn to not attempt
> to
> make a connection

How would that work if, say, the laptop leaves the building and
loses wireless to the corporate network?   In the setup you
describe all the connections die because the network goes
down. Seems to me it would
be better to always have a open vpn connection but don't
route to it when you're inside the firewall.  Some solution involving
a routing protocol would do this and then established connections 
would not break.

Routing protocols are supposed to deal with paths going up and down,
so why reinvent the wheel?




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackged Windows binaries? -- Problems building 2.1 rc15 on Windows XP

[Karl O. Pinc]

On 08/27/2010 11:16:40 AM, David Sommerseth wrote:
> On 27/08/10 16:20, Karl O. Pinc wrote:
> > On 08/27/2010 03:50:55 AM, David Sommerseth wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> On 09/04/09 19:44, Karl O. Pinc wrote:
> >>>
> >>> On 04/09/2009 07:58:46 AM, Karl O. Pinc wrote:
> > So, is it worth doing any work at all on this?

> 
> No problem!  I would say it makes sense to give some documentation 
> how
> to do this.  And you've already done a great job here!

Ok.  Good.



> >> [...snip...]
> >>
> >> +  Add the 2 lines:File
> >> + "myserver.ovpn"File "ca.crt" code> /
> >>>
> >> + to the nsi/openvpn.nsi file at the bottom 
> of
> >> + the section titled: Section "${P`'RODUCT_NAME}
> >> Service"
> >>^^^
> >> Is this really correct?
> >
> > Dunno.  At one point I tested everything.  This would include
> > in the new installer those files, which are what's needed to
> > run a openvpn client that validates the server with a certificate.
> > The point of the entire exercise being to create a single installer
> > that contains everything needed to run openvpn.
> 
> Understood.  It was just the syntax with ${P`'RODUCT_NAME} which
> looked
> very odd to me.  If it's correct, I won't object to that.

That's what you do in m4 to ensure text is not macro expanded.
(I guess I'm doing some m4 here...)



Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackged Windows binaries? -- Problems building 2.1 rc15 on Windows XP

[Karl O. Pinc]

On 08/27/2010 03:50:55 AM, David Sommerseth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 09/04/09 19:44, Karl O. Pinc wrote:
> > 
> > On 04/09/2009 07:58:46 AM, Karl O. Pinc wrote:
> >>
> >> On 04/09/2009 01:01:50 AM, Alon Bar-Lev wrote:
> >> > On Thu, Apr 9, 2009 at 6:03 AM, Karl O. Pinc <k...@meme.com>
> wrote:
> >> > > It occurs to me that if I want to do more than
> >> > > beg I should submit a patch, so one is attached.
> 
> Sorry it has taken way too long time to get this one reviewed.  It's
> just been quite a lot to do, and this was not considered critical
> enough.
> 
> > It occurs to me that it's no good having an unpackaged
> > Windows binary archive without instructions regarding
> > how to use it.
> 
> Agreed!

So, is it worth doing any work at all on this?
I have not had the time to add to the weekly irc meeting
agenda and advocate live.  The arguments previously presented
in email cover the subject already.

> 
> > Attached is a patch to INSTALL-win32.html that
> > documents how to make a custom Windows installer using
> > the archive produced by my previous patch.
> > 
> > I hope OpenVPN will consider these patches for inclusion.
> 
> Review follows below.
> 
> 
> - --- INSTALL-win32.html  2005-10-18 03:46:47.0 -0500
> +++ INSTALL-win32.html.patched2009-04-09 12:38:59.0
> -0500
> ^^
> 
> This is not a file which is available directly in the source tree.  
> It
> is in best case generated somehow.  How that is done, I have no idea
> (I'm not using Windows platform for development).  However, there is 
> a
> INSTALL-win32.txt file - the patch should really be against that file
> -
> and without the HTML mark-ups.  Please do so against the git tree,
> preferably the feat_misc or master branch.

The file _was_ in the source tree, but is no longer.  I will
find the appropriate new file.

> 
> [...snip...]
> 
> +Note that an MS Windows machine is not a requirement. p>
> 
> Why so? If I've understood you correctly, if having the needed 
> windows
> binaries available, you just rebuild the NSIS installer.  This should
> be
> possible to do also in Linux or *BSD.

We are in agreement here.  Did you miss the word "not" in the
sentence or is there some other vagueness in the wording?

> [...snip...]
> 
> + Nullsoft Install System
> +  href="http://www.nullsoft.com/free/nsis/;>http://www.nullsoft.com/
> free/nsis/
> 
> This redirects to: http://nsis.sourceforge.net/Main_Page

Probably an a stale link.

> 
> [...snip...]
> 
> + Unpack the OpenVPN unpackaged windows binaries.  The
> + result should be a directory, the unpacked OpenVPN binary
> + directory.  This directory should have subdirectories.
> 
> Confusing sentences ... a lot of unpacked unpacked binaries unpacked.

How about "Unpack the OpenVPN tar file.  The result ..."?

> +
> + Using Internet Explorer (TM) navigate to the
> + nsi subdirectory of the unpacked OpenVPN 
> binary
> + directory.
> 
> Using "Internet Explorer"?!?  Why not "Using the file browser ..."?

I don't know.  I'll look into it if we go farther.
> 
> + Right click on the icon labeled openvpn 
> and
> + select "Compile NSIS script".  Un*x users can use the
> + makensis openvpn.nsi command.
> +
> 
> Okay, here you have the cross-platform stuff.  I'd probably prefer to
> state "Linux or *BSD users", as that is the supported platforms by
> NSIS.

Ok.


> 
> [...snip...]
> 
> +  Add the 2 lines:File
> + "myserver.ovpn"File "ca.crt"<br /
> >
> + to the nsi/openvpn.nsi file at the bottom of
> + the section titled: Section "${P`'RODUCT_NAME}
> Service"
>^^^
> Is this really correct?

Dunno.  At one point I tested everything.  This would include
in the new installer those files, which are what's needed to 
run a openvpn client that validates the server with a certificate.
The point of the entire exercise being to create a single installer
that contains everything needed to run openvpn.

> 
> + SecService
> +
> +
> +Note that putting your configuration and CA certificate files 
> into
> +the nsi subdirectory is not the most organized 
> approach.
> +It is simply the easiest way to get started with NSIS.
> 
> What about to explain properly how to do it more organised?  Most
> users
> won't care, and when they learn the sloppy

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/26/2010 10:23:21 AM, David Sommerseth wrote:
> On 26/04/10 16:47, Karl O. Pinc wrote:
> >
> > Speaking of the standard release process there is still this 
> thread:
> >
> > Re: [Openvpn-devel] Unpackged Windows binaries? -- Problems 
> building
> > 2.1 rc15 on Windows XP
> >
> > and its patch for releasing unpackaged MS Windows binaries;
> > quite similar to what you're proposing for OS/X.  There has been
> > no response from this list regarding this for quite some
> > time despite repeated requests, unless I missed something
> > somewhere along the line.

For reference I'm linking to the original thread here.

http://thread.gmane.org/gmane.network.openvpn.devel/2566/focus=3171

I wrote Samuli Seppänen to get this link added to the trac
entry for the upcoming IRC meeting as further reference,
or alternately to get access to trac.
(The parent of this thread, before the subject was changed, 
is an agenda item but there's no reference to
the prior thread.)  I have not heard
back so am writing here to be sure the link is available
to anyone who needs it for the meeting.

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/27/2010 05:58:43 AM, Peter Stuge wrote:
> Karl O. Pinc wrote:
> > IMO OpenVPN is encouraging bad practices by supplying packages for
> > distros that include OpenVPN.
> 
> Ideally the package for that distro as made by OpenVPN is always
> equivalent to the one made by the distributor.

I'm writing again in case someone thinks this is a reason why it's
fine for an end-user to get their OpenVPN from openvpn.net.

The problem is not the initial package installation.  It's
keeping up with changes over time.  That's the big
service that distro's provide.  Installing a single non-distro
application is no big deal.  More than a few become a problem
to keep up with to the point where eventually things stop
working.  Packages makes it easier to keep track of what's
what and keep things updated, in comparison to ./configure;
make; make install, but the point of diminishing returns
is soon reached regardless.

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/27/2010 05:58:43 AM, Peter Stuge wrote:
> Karl O. Pinc wrote:
> > IMO OpenVPN is encouraging bad practices by supplying packages for
> > distros that include OpenVPN.
> 
> Ideally the package for that distro as made by OpenVPN is always
> equivalent to the one made by the distributor.
> 
> What do I mean? I mean that I'm happy with .spec files and the likes,
> that make up the source code for a particular kind of binary package,
> being committed upstream.
> 
> And if they are, then it's of course fairly easy for upstream to use
> them, and to make packages which are at the very least compatible
> with the distribution.

I agree.
It is useful for OpenVPN to distribute .spec files and
equivalents for use by disto packagers.

> 
> And, I think that since it is downloaded from a site other than the
> distributor's, users who actually do grab packages "manually" will be
> able to tell the difference from a package delivered by the
> distributor.

The question is not whether users can tell the difference, it's
whether users know enough to know the advantages of getting
their packages from their distro.  I believe that most users
are unaware of these advantages because they have experience 
only with OSs that force them to arrange for their own 
systems integration.  IMO the widespread failure to integrate disparate
software and the consequent gradual degradation of so many systems,
often ending in a disk wipe and OS re-install, demonstrates
the extent of the problem.  While OpenVPN's users are clearly
the cream of the crop, hip, techo-savvy, and sporting
shiny white smiles, I don't believe they are immune
and the OpenVPN project should encourage them to make
good choices.  This would help toward a good long-term
OpenVPN experience.  The current policy that makes
pre-packaged downloads available without explanation
does nothing to encourage good sysadmin practice and
puts a bad choice one click away.

Giant problem?  No.  They'll always be plenty of ways
to make bad choices. I'd be ok with making distro specific packages 
available so long as you also tell the end-user they are 
probably better off without them.  :)

Regards,

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/26/2010 02:11:26 PM, Karl O. Pinc wrote:
> On 04/26/2010 11:53:19 AM, Peter Stuge wrote:
> > Karl O. Pinc wrote:
> > > the project is already releasing unpackaged Linux
> > > binaries
> > 
> > Really?
> 
> They seem to have stopped sometime after July 30 2008.
> 
> http://web.archive.org/web/20080730205524/openvpn.net/index.php/
> downloads.html

Sheesh Peter, you are right.  That pages has source downloads
and a MS Windows installer.  And it's the same page I recall
seeing forever.

Nothing anywhere about non-MSWindows binaries.

I completely mis-remembered, and didn't even see my mistake
when I called up the old page.  Sorry about that.

I seem to be making a habit of making false statements
on this list.  I'll see if I can fix that.

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/26/2010 09:46:06 PM, Toby Thain wrote:
> 
> On 27-Apr-10, at 12:19 PM, Karl O. Pinc wrote:
> 
> > On 04/26/2010 06:19:31 PM, Toby Thain wrote:
> >>>
> >>>
> >>
> >> I don't think unpackaged OS X binaries are very useful, which is
> why
> >> I
> >>
> >> created the pkg+dmg.
> >
> > I agree, because the Apple development kit is shipped,
> > if not installed, on every Mac.
> 
> It ships on the DVD but most people never install it, of course.
> 
> >  (Last I looked.)  And
> > because ./configure ; make is painless.
> 
> To use your argument from above -- imho much too complex for most end 
> 
> users. As well as requiring Apple Developer Tools (they have to go  
> find the original DVD, which may or may not even be possible), this  
> involves locating and downloading two source archives from two  
> different sites, and configuring and building them both; beyond the  
> pale for non-technical users, even though it's trivial for "us".

I'm not following you here.  I thought we were talking about whether
unpackaged OS/X binaries were useful to anybody.  The answer being
no because developers and packagers are the only people who need 
them and developers and packagers can easily create OS/X binaries.

> 
> The pkg/dmg is, on the other hand, a genuine one click install. (Even 
> 
> if you have to do a 2nd key install, which pkg has to be built  
> individually and distributed securely anyway.)

Depending on the degree of security required it could be enough
to key the server but not the client.  It does not matter to
my argument though, if you're going to make individualized packages
for each user you may as well put everything required into
the package you supply.  Having to compile binaries for MS Windows
becomes a big sticking point when making an all-inclusive MS
Windows installer; because you're already making an installer
you know how to do that and you've got a working example
of the OpenVPN installer as a starting point.

> It seems logical to me that an OS X binary dmg could be on the 
> OpenVPN
>  
> downloads page, giving a similar level of convenience to "yum install 
> 
> openvpn" or "apt-get install openvpn" or "emerge openvpn".

Sure.  Packages can be useful to end-users.

> 
> One thing that should *not*, in my opinion, be encouraged at all by  
> OpenVPN, are third party package managers (MacPorts, Fink, Homebrew  
> etc) as the binary route on OS X. That seems to do more harm than
> good.

I have no opinion.  I suppose it depends on the degree of systems
integration provided by the 3rd party.  I assume this is usually
none, in which case there's no point and the end-user may as well
get their packages straight from the source.

> 
> 
> If I were deploying it, rather than hacking on it, I would expect a  
> binary installer to be available for my platform, at
> http://openvpn.net

I'd expect my distro provider to supply it, be sure it integrates
with everything else, and support security fixes.  YMMV.
Of course this assume a distro.  Users of commercial OSs
are generally expected to arrange for their own systems
integration and application support.  In that case the
typical user should follow your advice and get their
packages direct from OpenVPN.

Which raises another issue.  IMO OpenVPN is encouraging
bad practices by supplying packages for distros that
include OpenVPN.  The typical user is more likely to have
a bad OpenVPN experience, over time, when using packages
obtained directly from OpenVPN than when using packages
created by their distro, for the reasons outlined above
and earlier in this thread.  Some people may benefit
from having the most recent OpenVPN and obtaining it
straight from the project, but these people are also
the most likely to be able to package it themselves.
If this is all true then the OpenVPN project is doing
it's userbase a dis-service by making, say, packages
for Red Hat available for download because this is
tacit encouragement of bad practice.  At minimum
there should be a warning to educate the naive user.

The situation is different for MS Windows and OS/X.
Packages are needed for those platforms and whatever
other commercial OSs the project wants to support.

There.  Now I've wandered far from the original
topic and likely offended someone too.
Mission accomplished.  :-P

Regards,


Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/26/2010 06:02:46 PM, David Sommerseth wrote:
> On 26/04/10 21:11, Karl O. Pinc wrote:
> > On Debian all I had to do was "aptitude install nsis" and then
> > run it to make MS Windows installers.  Plug and play, no
> > compiling necessary.
> >
> 
> Just a little nitpick, when you run makensis, that's actually
> compilation of the installer - even when you're doing it on Linux. 
> You
> get a Windows binary as the result.

As long as we're nitpicking... ;-)

That's interesting.  I figured the nsis install scripts
were interpreted and, if I thought about it at all,
running makensis setup some data structures and did
some linking.

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/26/2010 06:19:31 PM, Toby Thain wrote:
> 
> On 27-Apr-10, at 1:58 AM, Karl O. Pinc wrote:
> >
> > The problem addressed is that there only binaries available
> > for MS Windows are pre-packaged in an installer executable.
> > This means that anyone who wants stock binaries but a
> > modified installer has to recompile from source.
> 
> For the OS X package, I chose to simply make two packages - one the  
> generic binaries, and one for whatever configuration and keys are  
> needed for a particular deployment. Could you do the same on Windows?

Sure, but this greatly increases the complexity for the
end-user.  Just adding another installer at least doubles the
complexity.  A custom install can be one-click.  The stock
OpenVPN installer (last I looked) presented the user
with many choices and is far more complex than a 1-click
install.

Getting the users to do anything at all can be tricky
(especially at the outlying ends of the pay scale).
The less that can go wrong the better.

> > But this only makes sense if OpenVPN _will_ release
> > unpackaged MS Windows binaries.  It makes sense to me;
> > the project is already releasing unpackaged Linux
> > binaries and it now talking about doing the same
> > for OS/X binaries.
> 
> I don't think unpackaged OS X binaries are very useful, which is why 
> I
>  
> created the pkg+dmg. 

I agree, because the Apple development kit is shipped,
if not installed, on every Mac.  (Last I looked.)  And
because ./configure ; make is painless.  MS Windows on
the other hand requires additional software 
to compile anything.  And the FOSS choices, which
are the the ones most universally available, are non-trivial
to install and use.  

I'd bet cross compiling  Un*x-to-Mac is easier too, but 
I have no experience to back that up.
Now that OpenVPN is accepting more patches cross compiling
Un*x-to-MSWindows will probably get easier but it will
never be easy.

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/26/2010 11:53:19 AM, Peter Stuge wrote:
> Karl O. Pinc wrote:
> > the project is already releasing unpackaged Linux
> > binaries
> 
> Really?

They seem to have stopped sometime after July 30 2008.

http://web.archive.org/web/20080730205524/openvpn.net/index.php/
downloads.html

It's hard to tell when because archive.org does not appear
to be allowed to archive the site any longer.  Or at least 
there's nothing more recent.  (This seems silly.  I wonder why.)

(I clearly haven't been downloading binaries in a while.
Probably because I rely on my distro for binaries so
they can do the systems integration and security patches, 
or I am getting development from CVS/git.

IMO people who don't rely on their distro for systems integration
and security patches are asking for trouble.  There are of course
always reasons to make specific exceptions, RH comes to mind. :)

Is OpenVPN in RHEL6?)

> 
> > and it now talking about doing the same for OS/X binaries.
> 
> Recently discussed work for contrib/ produces a .dmg, very much a
> package in my view.

Ok.  I don't know much about .dmg.  I thought they were basically
tarballs by another name in that they just stick stuff somewhere.
My Mac usage is sporadic, sorry.

> 
> 
> > There's clear utility.
> 
> I guess it depends. I'm not sure that I agree that compilation is a
> much bigger bother than (cross-)compiling the NSIS installer..

On Debian all I had to do was "aptitude install nsis" and then
run it to make MS Windows installers.  Plug and play, no 
compiling necessary.

Regards,

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

[Karl O. Pinc]

On 04/26/2010 10:23:21 AM, David Sommerseth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 26/04/10 16:47, Karl O. Pinc wrote:
> > Speaking of the standard release process there is still this 
> thread:
> > 
> > Re: [Openvpn-devel] Unpackged Windows binaries? -- Problems 
> building
> 
> > 2.1 rc15 on Windows XP
> > 
> > and its patch for releasing unpackaged MS Windows binaries;
> > quite similar to what you're proposing for OS/X. 

> Thanks for pushing this.  I am honestly not quite sure were we stand
> with that patch.  And since I understand the Windows building least 
> of
> all, I've refrained from going into details of this one so far.  It
> has
> not been my intention of ignoring this patch.  I'm primarily focusing
> on
> the platforms I happen to understand better, and hope others will
> chime
> in on the other issues.
> 
> But as responses are missing, I'll try to find some time in the near
> future (this week is crazily hectic for me) - to see if I can
> understand
> what your patch solves.  That is a little bit unclear to me, as the
> patch I'm looking at seems to just make a tarball with compiled
> binaries
> ... Right now, I do not immediately see what problem that solves.  
> But
> I'm pretty sure I'm overlooking something!
> 
> Btw, you mentioned in some of the threads that you would look at some
> of
> the docs for this as well.  I remember vaguely something about 
> another
> set of patches for HTML files - which I can't say I've seen in the
> source tree.  That would be good to get into the tree together with
> this
> patch when I've looked at it a bit better.

It's a packaging policy issue.

The problem addressed is that there only binaries available
for MS Windows are pre-packaged in an installer executable.
This means that anyone who wants stock binaries but a
modified installer has to recompile from source.

There are many reasons why one would want a non-stock
MS Windows installer -- the foremost being to include
an OpenVPN configuration file that allows connections
between pre-designated endpoints.  One might want to
go so far as to include certificates in the installation 
to secure the communications channel.  ;-)
Creating custom installation executables is
relatively easy, especially as the OpenVPN code base
includes a working config file that's used to make
the installer OpenVPN distributes.  But of course
OpenVPN binaries are a requirement before packaging
can be attempted.

Recompiling is both complicated and error prone.  Historically
there are a number of issues that make compiling difficult.
I recall problems with mingw versions
when compiling on MS Windows and some other sort of problems
when trying to cross compile from Linux.  In any case it's
clear that compiling will always be relatively complicated
and time-consuming to setup in comparison with downloading
binaries.

So, there are 2 patches.  The first is to the OpenVPN
build process.  It produces unpackaged MS Windows binaries
and (last you wrote) it works.  The second patch is to
the OpenVPN documentation.  It documents that the
binaries exist and when you want them.  It does not
apply because the OpenVPN website has since been
restructured.   The doc patch needs to be re-worked
to put the text in the appropriate place.

But this only makes sense if OpenVPN _will_ release
unpackaged MS Windows binaries.  It makes sense to me;
the project is already releasing unpackaged Linux
binaries and it now talking about doing the same
for OS/X binaries.  There's clear utility.  Regardless,
this is a policy decision.  Getting a resolution on 
packaging policy seems to me to be the first step.

If OpenVPN _won't'_ release unpackaged MS Windows
binaries I'd like to know why so it would be
nice if whomever moves this forward, as with
any other patch, solicits more than a yes/no answer.

Regards,

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] Serial number export, fixed

[Karl O. Pinc]

On 04/26/2010 05:48:38 AM, Davide Brini wrote:
> On Monday 26 Apr 2010 11:04:16 David Sommerseth wrote:
> > 
> > Agreed, but from experience with many users ... it's a lot of users
> who
> > just take a script and try it out without even looking at the 
> script
> > itself.  So if the script could fail gracefully giving a hint like
> > "you've not done as I told you to", some support issues will be
> avoided.
> 
> Ok, that makes sense. I didn't look at it this way, but then I
> perfectly know 
> what you mean, so I'll change it to exit if it detects that something
> is not 
> set properly.

FWIW, and I don't know what the code does so I can't say
whether this would be useful, but if you go to http://example.com
or http://www.example.com (but not http://foo.example.com) you
get a bare-bones web page explaining that you're using a
reserved domain.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [ANN] OS X packages - OpenVPN 2.1.1

[Karl O. Pinc]

On 04/26/2010 03:42:37 AM, Arnoud Vermeer wrote:
> Hi Toby,
> 
> I for one appreciate your effort and would love to see this in the
> standard
> release process.

Speaking of the standard release process there is still this thread:

Re: [Openvpn-devel] Unpackged Windows binaries? -- Problems building 
2.1 rc15 on Windows XP

and its patch for releasing unpackaged MS Windows binaries;
quite similar to what you're proposing for OS/X.  There has been
no response from this list regarding this for quite some
time despite repeated requests, unless I missed something
somewhere along the line.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] Serial number export, fixed

[Karl O. Pinc]

On 04/26/2010 03:56:16 AM, Davide Brini wrote:
> On Monday 26 Apr 2010 00:13:39 David Sommerseth wrote:

> > > +# OCSP responder URL (mandatory)
> > > +ocsp_url="http://some.ocsp.server/;
> > > +#ocsp_url="https://some.secure.ocsp.server/;
> > 
> > Wouldn't it be better to use a more valid URL?
> 
> And what could it be? I can put in the OCSP URL of some well-known 
> CA,
> but 
> then if the user is using their own server, that would be meaningless
> anyway. 
> But I'm open to suggestions.

I would suggest example.com, which would be compliant with
RFC 2606 "Reserved Top Level DNS Names".



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Status Message Missing IP Address

[Karl O. Pinc]

On 04/24/2010 09:34:46 AM, open...@rkmorris.us wrote:
> 
> 
> Hi,
> 
> This makes sense to me on the server side, but I'm running the
> management interface on the client ... why would it not know (or at
> least report) it's IP address?

Because it's not OpenVPN's IP address it's the client OS's
IP address.  OpenVPN is acting as a virtual wire.  The
client is obtaining it's IP as it usually does, just from
a server on the other end of the wire.  At least if I'm
understanding your configuration.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Slight modification to the contrib client.up script: DNS in server order

[Karl O. Pinc]

On 04/21/2010 09:13:35 AM, Toby Thain wrote:
> 
> On 21-Apr-10, at 11:49 PM, Richard Monk wrote:
> 
> > I had an issue come up where the clients were getting DNS entries 
> in
>  
> > the
> > reverse order the server sends them when using the client.up 
> contrib
> > script.  Since the DNS servers on our system are in order from
> > closest->farthest network wise from the VPN server, having them
> > backwards caused some performance issues.
> 
> Have you considered a local caching DNS with forwarding?

I don't see how this will solve the problem.
What if the closest _is_ a local caching DNS with forwarding
to the next farthest out?  You still want all the DNS servers
available in case one is down for some reason.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackged Windows binaries? -- Problems building 2.1 rc15 on Windows XP

[Karl O. Pinc]

Hello,

What's happening with this patch?  Does OpenVPN
want it?

On 04/01/2010 10:19:01 AM, Karl O. Pinc wrote:
> So, what is the status of this patch?  Would Openvpn
> release "unpackaged" MS Windows binaries?  If so
> you can apply the code patch and I'll rework the
> documentation patch into where ever the documentation
> currently exists.
> 
> On 02/28/2010 09:48:46 PM, Karl O. Pinc wrote:
> > On 02/28/2010 06:27:54 AM, David Sommerseth wrote:
> > > On 09/04/09 05:03, Karl O. Pinc wrote:
> > 
> > 
> > 
> > > > The OpenVPN devs have a "built" source tree in which they run
> > > > install-win32/buildinstaller.  My point being that
> > > > if they would package it up
> > > > and release it alongside the resultant installer
> > > > none of these sorts of issues would ever come up.
> > > >
> > > > Attached is a patch that produces a un-nsis-installer
> > > > windows binary release as part of the build process.
> > > >
> > > > Apply it with:
> > > >
> > > > cd openvpn
> > > > patch -p1 < buildbinaryrelease.patch
> > > >
> > > > The result is a file named something like:
> > > > openvpn-2.1_rc15-winbinaries.tar.gz
> > > >
> > > > I deliberately produce a tar.gz file
> > > > rather than a zip file to keep
> > > > Windows people from downloading it accidentally
> > > > instead of the Windows installer exe.
> > > >
> > > > There is more work to be done.  The file needs to
> > > > be signed and put on the website every time there's
> > > > a release.  I don't see anything in svn to patch
> > > > that would aid this process.
> > > 
> > > Hi!
> > > 
> > > I'm going through the mailing list, picking up patches which 
> seems
> 
> > > not
> > > to be included.  Is this patch still interesting to get included? 
> > 
> > I would like to see it included.  
> > 
> > The goal is to allow people to create
> > custom installers for MS Windows without having to rebuild
> > the source or cross compile.  The point of the patch
> > is to support an "unpackaged" release of the MS Windows
> > binaries.  In other words raw binaries that are not
> > part of an installer, which can then be packaged
> > using the nsis installer to produce a custom install.
> > 
> > As noted above this means that the official OpenVPN project
> > would have to actually release such binaries.  If the
> > project does not want to do this there is no point in
> > having the patch.
> > 
> > So, this requires upstream approval.  In some ways this
> > is no different from other patches, except that it requires
> > ongoing work as new releases come out -- or if not that
> > then a change to whatever automated process (unavailable to
> > us, at least at the time the patch was written) that puts 
> > releases out to the public.
> > 
> > > This
> > > one applies cleanly to the master branch.
> > > 
> > > I see that this patch is also followed by this one:
> > > 
> > > <http://article.gmane.org/gmane.network.openvpn.devel/2581>
> > 
> > Yes.  The second patch is to the documentation so that people
> > know what to do with unpackaged MS Windows binaries.  Not
> > much point in releasing the binaries unless there's documentation.
> > 
> > > 
> > > This patch do not apply at all, as the standard checked out tree
> do
> > > not
> > > have INSTALL-win32.html, only INSTALL-win32.txt.  Is this 
> correct?
> 
> > I
> > > can't find this HTML file in the 2.1_rc15 nor 2.1_rc16, which was
> > > current when this patch was sent to the mailing list.
> > 
> > The OpenVPN site has restructured since this patch was written.
> > 
> > I'd be happy to redo the documentation patch, but I don't see
> > any point in doing so without some assurance that the effort
> > will not be wasted.  How can I get some feedback on this?
> > 
> > Regards,
> > 
> > Karl <k...@meme.com>
> > Free Software:  "You don't pay back, you pay forward."
> >  -- Robert A. Heinlein
> > 
> > 
> > 
> --
> > Download Intel Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > ___
> > Openvpn-devel mailing list
> > Openvpn-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> > 
> > 
> > 
> > 
> 
> 
> 
> 
> Karl <k...@meme.com>
> Free Software:  "You don't pay back, you pay forward."
>  -- Robert A. Heinlein
> 
> 
> 




Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Unpackged Windows binaries? -- Problems building 2.1 rc15 on Windows XP

[Karl O. Pinc]

So, what is the status of this patch?  Would Openvpn
release "unpackaged" MS Windows binaries?  If so
you can apply the code patch and I'll rework the
documentation patch into where ever the documentation
currently exists.

On 02/28/2010 09:48:46 PM, Karl O. Pinc wrote:
> On 02/28/2010 06:27:54 AM, David Sommerseth wrote:
> > On 09/04/09 05:03, Karl O. Pinc wrote:
> 
> 
> 
> > > The OpenVPN devs have a "built" source tree in which they run
> > > install-win32/buildinstaller.  My point being that
> > > if they would package it up
> > > and release it alongside the resultant installer
> > > none of these sorts of issues would ever come up.
> > >
> > > Attached is a patch that produces a un-nsis-installer
> > > windows binary release as part of the build process.
> > >
> > > Apply it with:
> > >
> > > cd openvpn
> > > patch -p1 < buildbinaryrelease.patch
> > >
> > > The result is a file named something like:
> > > openvpn-2.1_rc15-winbinaries.tar.gz
> > >
> > > I deliberately produce a tar.gz file
> > > rather than a zip file to keep
> > > Windows people from downloading it accidentally
> > > instead of the Windows installer exe.
> > >
> > > There is more work to be done.  The file needs to
> > > be signed and put on the website every time there's
> > > a release.  I don't see anything in svn to patch
> > > that would aid this process.
> > 
> > Hi!
> > 
> > I'm going through the mailing list, picking up patches which seems 
> > not
> > to be included.  Is this patch still interesting to get included? 
> 
> I would like to see it included.  
> 
> The goal is to allow people to create
> custom installers for MS Windows without having to rebuild
> the source or cross compile.  The point of the patch
> is to support an "unpackaged" release of the MS Windows
> binaries.  In other words raw binaries that are not
> part of an installer, which can then be packaged
> using the nsis installer to produce a custom install.
> 
> As noted above this means that the official OpenVPN project
> would have to actually release such binaries.  If the
> project does not want to do this there is no point in
> having the patch.
> 
> So, this requires upstream approval.  In some ways this
> is no different from other patches, except that it requires
> ongoing work as new releases come out -- or if not that
> then a change to whatever automated process (unavailable to
> us, at least at the time the patch was written) that puts 
> releases out to the public.
> 
> > This
> > one applies cleanly to the master branch.
> > 
> > I see that this patch is also followed by this one:
> > 
> > <http://article.gmane.org/gmane.network.openvpn.devel/2581>
> 
> Yes.  The second patch is to the documentation so that people
> know what to do with unpackaged MS Windows binaries.  Not
> much point in releasing the binaries unless there's documentation.
> 
> > 
> > This patch do not apply at all, as the standard checked out tree do
> > not
> > have INSTALL-win32.html, only INSTALL-win32.txt.  Is this correct? 
> I
> > can't find this HTML file in the 2.1_rc15 nor 2.1_rc16, which was
> > current when this patch was sent to the mailing list.
> 
> The OpenVPN site has restructured since this patch was written.
> 
> I'd be happy to redo the documentation patch, but I don't see
> any point in doing so without some assurance that the effort
> will not be wasted.  How can I get some feedback on this?
> 
> Regards,
> 
> Karl <k...@meme.com>
> Free Software:  "You don't pay back, you pay forward."
>  -- Robert A. Heinlein
> 
> 
> --
> Download Intel Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 
> 
> 
> 




Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Karl O. Pinc]

On 03/13/2010 05:34:19 PM, Matthias Andree wrote:
> Karl O. Pinc wrote on 2010-03-10:

> > But, you _don't_ have to run ./configure every time.  You
> 
> You do.

Yes.  Thanks.  I don't know what I was thinking.  


Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/11/2010 04:42:07 PM, Stefan Monnier wrote:
> >> Let's not add more complexity to openvpn itself, I'd be much
> happier if 
> > You just don't understand.
> > The complexity *WILL* be in OpenVPN, if we decide to support
> > "route-gateway dhcp" for non-Windows platforms.
> 
> I'm not sure what "route-gateway dhcp" does, so maybe that's part of
> the
> reason why we disagree.

I don't think that's the problem.  Route-gateway dhcp makes the
openvpn server into a dhcp gateway so a remote dhcp server
can be used to configure the local VPN interface.  Right?

(It suddenly occurs to me that you probably don't want
the entire local lan using the remote dhcp server,
unless you do.)

  I thought the discussion was about how to
> make
> DHCP work over an OpenVPN bridge (i.e. a TAP device) under systems
> like
> GNU/Linux.  On those systems, the only thing you need to do is to 
> make
> sure that things like ifplugd correctly receive the info about when
> the
> tunnel goes up and down.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/11/2010 09:10:23 AM, David Sommerseth wrote:

> I agree to your points, from a theoretical point of view.  But from a
> practical point of view, I'm not sure how possible it is to find a
> more
> generic solution which can be used on all *nix based setups.  AFAIK,
> ifplugd is very Linux oriented, and depends on features found in that
> kernel.  What about *BSD, Solaris or other Unix based OSes?

OpenBSD has ifstated.  I'd be surprised if the others didn't have
something similar.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Karl O. Pinc]

On 03/10/2010 11:54:52 AM, David Sommerseth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/03/10 18:39, Karl O. Pinc wrote:
> > On 03/10/2010 11:19:13 AM, Alon Bar-Lev wrote:
> >> I will try to explain again.
> >>
> >> You have two roles of environments:
> >>
> >> 1. Developer/packager workstation.
> >>
> >> 2. Target environment.
> >>
> >> For example, 1 would be my computer, and 2 would be the old redhat
> >> computer.
> >>
> >> You go to (1) and do:
> >> $ autoreconf -ivf
> >> $ ./configure && make dist
> >>
> >> Now, you transfer the tarball to users, the old redhat computer is 
> >> one
> >> of them. The tarball will work WITHOUT ANY
> AUTOCONF/AUTOMAKE/LIBTOOL
> >> installed.
> >>
> >> I use older environments as (2) such as solaris-8.
> > 
> > And you don't generally want to be running ./configure from within
> > a rpm specfile, so the same is true of using the rpm tools:
> 
> This is not correct.  In fact, you often use the %configure macro in
> %build, which does call ./configure.  The only "allowed" exception
> from
> not calling %configure is when ./configure is not a native autotools
> generated configure script.

Ok.  I'm totally wrong here.

But how is it then that Alon does not run ./configure
on machine 2 above?

> 
> > On machine 2 you download the tarball, the specfile, (and
> > any patches the rpm maintainer wants to include in the
> > packaged version) and run the rpm build tools on the
> > spec file to build a binary rpm.  
> > 
> > Note that http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html
> > says: 
> > 
> > "Once the %prep script has gotten everything ready for the build,
> the %
> > build script is usually somewhat anti-climactic — normally invoking 
> > make, maybe a configuration script, and little else. 
> 
> It's %build which need to do the %configure.  All patching must 
> happen
> on %prep.  But you are right, if there are applied patches which
> updates
> some of the autotools generated files, I believe autotools need to be
> run again.  Right, Alon?

Nothing should patch the autotools generated files, just the autotools
source files.  Right?



Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Karl O. Pinc]

On 03/10/2010 11:41:49 AM, Alon Bar-Lev wrote:
> On Wed, Mar 10, 2010 at 7:39 PM, Karl O. Pinc <k...@meme.com> wrote:
> > In other words ./configure is not expected to be run under normal
> > circumstances.
> >
> > The whole point of autoconf is to produce something that can
> > be made into a tarball that only requires "make; make install"
> > to compile and install.
> 
> You do not understand the tools. Nor the common use of them.
> 
> You *MUST* run ./configure when compiling from sources.

You are right, on all of the above.  I don't use them every
day. 

But, you _don't_ have to run ./configure every time.  You
yourself wrote that you do the ./configure on the _new_
machine, and then move the tarball to the old machine
and recompile.  This is often the situation, or at least
I found so, when making rpm spec files.

You are quite correct in pointing out that ./configure
should be able to be run on the old machine, which
means that it can be executed within the build portion
of the spec file.

Thanks for the correction and please tell me if I'm
wrong again.

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Karl O. Pinc]

On 03/10/2010 11:37:57 AM, David Sommerseth wrote:
> On 10/03/10 18:26, Peter Stuge wrote:

> > The only way autoconf on that RHEL4.6 would be relevant is if those
> > RHEL4.6 systems strictly need to build directly from git source, as
> > opposed to building from a prepared tarball. Is that the case?
> 
> I will get that clarified on the meeting tomorrow, as this might be a
> scenario.  But to be honest, I have troubles seeing that people want
> to
> do active development on RHEL4.6, at least do changes which require
> changing autotools files or pulling down SVN or git trees.

And, to reiterate, applying patches within an rpm
spec file is normal, expected, and part of the
rpm design so a certain level of "development" is supported.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

[Karl O. Pinc]

On 03/10/2010 11:19:13 AM, Alon Bar-Lev wrote:
> I will try to explain again.
> 
> You have two roles of environments:
> 
> 1. Developer/packager workstation.
> 
> 2. Target environment.
> 
> For example, 1 would be my computer, and 2 would be the old redhat
> computer.
> 
> You go to (1) and do:
> $ autoreconf -ivf
> $ ./configure && make dist
> 
> Now, you transfer the tarball to users, the old redhat computer is 
> one
> of them. The tarball will work WITHOUT ANY AUTOCONF/AUTOMAKE/LIBTOOL
> installed.
> 
> I use older environments as (2) such as solaris-8.

And you don't generally want to be running ./configure from within
a rpm specfile, so the same is true of using the rpm tools:

On machine 2 you download the tarball, the specfile, (and
any patches the rpm maintainer wants to include in the
packaged version) and run the rpm build tools on the
spec file to build a binary rpm.  

Note that http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html
says: 

"Once the %prep script has gotten everything ready for the build, the %
build script is usually somewhat anti-climactic — normally invoking 
make, maybe a configuration script, and little else. 

...

Either the commands required to build the software are simple (such as 
a single make command), or they are so unique that a macro wouldn't 
make it easier to write the script. "

In other words ./configure is not expected to be run under normal
circumstances.

The whole point of autoconf is to produce something that can
be made into a tarball that only requires "make; make install"
to compile and install.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/09/2010 11:27:13 AM, David Sommerseth wrote:
> On 09/03/10 17:41, Karl O. Pinc wrote:
> > On 03/09/2010 10:16:37 AM, David Sommerseth wrote:
> >
> >>> Over-automating things will cause people headaches.
> >>> You don't want to willy-nilly startup a dhcp client
> >>> and have all your interfaces configured with dhcp without
> >>> your consent.
> >>
> >> Exactly!  Which again moves it more in the direction of some
> built-in
> >> DHCP client in OpenVPN, but as stated earlier - that mostly solves
> >> the
> >> core DHCP issues - but not the resolv.conf issue.
> >
> > I'm not at all sure it solves the core issues, which is that
> > an already running dhcp client won't have auto-detected
> > the tap interface that OpenVPN creates -- iff OpenVPN is
> > started after the dhcp client.
> 
> Can you actually start an DHCP client on a non-existing TAP device?  
> I
> don't think so.

No.  That's my point.  The tap device won't exist if you start
openvpn after starting dhcp.

>  And I haven't seen any clients which do have such
> auto-detect features

man dhclient says: "If no interface names are specified
   on the command line dhclient will normally  identify
   all  network  interfaces,  eliminating non-broadcast
   interfaces if possible,  and  attempt  to  configure
   each interface."


 ... I begin to feel we're talking about 
> different
> things now.

You may be closer to reality than me.  I'm not a dhcp expert,
at least not when it comes to experience with various client
implementations and especially not when it comes to tap
interfaces.  So I hope I'm not making things more confusing
when I point out potential problems I see.  

> 
> > This is the
> > core issue, right? Otherwise it would just work so long
> > as dhcp is turned on.  I think we need to decide where
> > the problem really is before we decide how to fix it.
> 
> I don't think we're on the same page now.  The issue how I see it:
> There is a real DHCP server which provides DHCP clients network
> configurations automatically, including IP addresses, routes and
> default
> gateway, DNS/WINS servers, and a lot of the other options the DHCP
> server supports.
> 
> The challenge for OpenVPN in this is that now a separate DHCP client
> needs to be started via a --up script, and to be torn down via a
> --down
> script.  But this needs to be run as root (at least on most platforms
> I
> know about).
> 
> The problem, how I see it, is how to do this in an easier and more
> robust way, configuration wise - to make OpenVPN on *nix behave more
> like it does on Windows, where no extra configuration is needed at 
> all
> (if you ignore the DNS cache issues in Windows for now), it just
> works.
> 
> Please correct me, if you think I have made it too vague and simple,
> or
> simply wrong.

This is right.  Perhaps too simple in the case of dhcp clients
that support multiple interfaces.  This is especially true
if the dhcp server is started after the openvpn process
because then the dhcp server can see the tap interface
and configure it (and fiddle with resolv.conf) without 
anything having to be done on the openvpn side.
See also this bottom of this message for an alternate statement of
the problem.

> 
> > If you build a dhcp client into openvpn you push the problem in
> > the other direction.  Now you've, potentially, got
> > multiple dhcp clients running and you need to do
> > something to keep them from interfering with each other.
> 
> Why is this an issue?  Unless they operate on each separate network
> segment, this shouldn't cause any unexpected behaviour.  And it's not
> uncommon to see boxes with multiple interfaces running separate DHCP
> clients per interface, and that don't seem to cause any problems in
> those setups I've done that with.

The issue is when two clients want to assign an address to 
one interface.  I don't know if dhclient will autodetect tap
interfaces but if so, or if anything else does, then you get
2 clients doing dhcp for one interface.


> > You can't rely on processes being started and stopped
> > in boot-time order because the sysadmin might start
> > and stop services as needed to maintain the system
> > and you don't want surprising things to happen.
> > (The principle of least surprise is a good one.)
> 
> Exactly, and if a user stops OpenVPN, the DHCP client for that TAP
> interface should also be taken down, right?  And if the OpenVPN is
> started at boot time, OpenVPN will take care of getting the DHCP
> config
> when the link is established, right?  I don't see any obstacles here,
> nor any potential surprises.

You're assuming 

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/09/2010 10:16:37 AM, David Sommerseth wrote:

> > Over-automating things will cause people headaches.
> > You don't want to willy-nilly startup a dhcp client
> > and have all your interfaces configured with dhcp without
> > your consent.
> 
> Exactly!  Which again moves it more in the direction of some built-in
> DHCP client in OpenVPN, but as stated earlier - that mostly solves 
> the
> core DHCP issues - but not the resolv.conf issue.

I'm not at all sure it solves the core issues, which is that
an already running dhcp client won't have auto-detected
the tap interface that OpenVPN creates -- iff OpenVPN is 
started after the dhcp client.  

This is the
core issue, right?  Otherwise it would just work so long
as dhcp is turned on.  I think we need to decide where
the problem really is before we decide how to fix it.

If you build a dhcp client into openvpn you push the problem in
the other direction.  Now you've, potentially, got
multiple dhcp clients running and you need to do
something to keep them from interfering with each other.
You can't rely on processes being started and stopped
in boot-time order because the sysadmin might start
and stop services as needed to maintain the system
and you don't want surprising things to happen.
(The principle of least surprise is a good one.)
You may as well just statically configure your existing
dhcp client so that it knows to go looking for the
tap device.

I think the only way to go is to integrate with
anything that the local admin may decide to use
for dhcp/resolv.conf/etc.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/09/2010 08:01:32 AM, Stefan Monnier wrote:
> > bring the interfaces up
> > start dhcp client (if not triggered directly from the interfaces)
> > start openvpn
> 
> That is a misconfiguration in my book.  The only correct 
> configuration
> is when the dhcp client is triggered from the interface.  After all,
> openvpn may take half an hour to get the connection and it may lose
> the
> connection at some point and reconnect to another openvpn server (via
> round-robin DNS, for example) which might require a reconfiguration 
> on
> the dhcp side.

My understanding of dhcp is that the client is supposed to 
automatically reconfigure on lease expiration or whenever
the link goes up and down.  There's no reason to
restart a dhcp client just to connect to another dhcp
server because dhcp should also do this automatically.

I suppose it's possible that there are dhcp clients
that exit when the link goes down and must be restarted
but I don't know of any.  Then again I don't have
experience with various client implementations.
But it would seem kind of odd, having to restart
the dhcp client just because somebody unplugged
an ethernet cable.

The only reason why we're talking about restarting
dhcp clients in the first place is so that they
autodetect newly created tap devices.  If the
dhcp client is configured with the tap device, or once
it detects the tap device and the tap device stays
existent, all the dhcp clients I know of should just
be able to keep running and do what's needed as
links go up and down and dhcp servers come and go.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/09/2010 08:05:17 AM, David Sommerseth wrote:

>  On the other hand, ./configure
> could try to detect which DHCP client the system got and could use
> that
> as a default client to kick off.

I think this might cause more problems than it solves because
there's no guarantee that build hosts will have the same,
or any, dhcp client that is ultimately used.   I'm with
Peter Stuge regarding being able to support a choice
of clients, and having the wrong default in place can
just complicate things.

Maybe what makes the most sense from a package
management standpoint is to have the package installation
process autodetect the existing dhcp client so that whatever
the user has installed will be used (once the feature
is turned on with --route-gateway.)  I'm not sure how
to best facilitate this with OpenVPN.  Perhaps OpenVPN
should default to using something like
/etc/openvpn/route-gateway-dhcp-client and then
package installation can softlink that to whatever
dhcp client is installed.  

Over-automating things will cause people headaches.
You don't want to willy-nilly startup a dhcp client
and have all your interfaces configured with dhcp without
your consent.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/09/2010 12:47:36 AM, Peter Stuge wrote:
> Karl O. Pinc wrote:
> > The boot order that makes sense to me is:
> > 
> > bring the interfaces up
> > start dhcp client (if not triggered directly from the interfaces)
> > start openvpn
> > 
> > The problem is that if the dhcp client is started before openvpn
> > and openvpn is creating the tap interface then it's too late
> 
> At least some distributions work more like this:
> 
> foreach interface:
>   set link up
>   possibly start openvpn
>   address add

Ok.  So this then relies on openVPN retries to get the connection
open, because when openvpn starts it's not got addresses
in place to reach the other endpoint.  The only downside
is that the startup is not really synchronous so that if
later portions of the boot process are relying on having
the VPN available they'd better be able to retry too.

In this case it should "just work" on those distros, at least so
long as the "address add" part is configured to use dhcp.  Yes?

Anyone know if it does work?

Which distros work like that?  I'm most familiar with
Debian and RedHat, although I've not looked at openvpn
on RedHat in a while.  I seem to recall on these
that the sysV init stuff starts openvpn last.




Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/08/2010 05:09:49 PM, Stefan Monnier wrote:
> >> I think if the user just starts the dhcp client on an interface
> >> independently from the moment the interface goes up (or down), 
> this
> 
> >> is simply a misconfiguration.
> > I'm not sure I understand.  Are you saying that manually starting
> > a dhcp client means that the system is mis-configured because
> > it's not configured to do the right thing automatically?
> 
> No, I mean if the dhcp client is started for example in the
> boot scripts.

I see the boot scripts as problematic.  The boot order
that makes sense to me is:

bring the interfaces up
start dhcp client (if not triggered directly from the interfaces)
start openvpn

The problem is that if the dhcp client is started before openvpn
and openvpn is creating the tap interface then it's too late
for the dhcp client to autodetect (at least at startup).
You could start openvpn before the dhcp client, and that could be
a good solution, but it does not work if there are tun
interfaces because the interfaces won't have yet
gotten an ip address from dhcp.

Or am I missing something?



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/08/2010 02:26:13 PM, Peter Stuge wrote:
> Karl O. Pinc wrote:
> > > I know of at least four DHCP clients and I avoid dhclient as much
> as
> > > possible. It would be a tremendous mistake to tie OpenVPN to any
> one
> > > DHCP client IMO.
> > 
> > Only D is tied to dhclient.  A, B, and C, work fine with any dhcp
> > client daemon.  (Or A does anyway, B and C require configuration
> file
> > support for the interface.  I assume this is a common property of
> > dhcp clients.)
> 
> Actually no, neither dhcpcd nor pump nor udhcpc uses one.

dhcpd needs one if you're going to have different interfaces
that need different dhcp options.

> 
> 
> > It would be nice not to force use of a particular client.
> 
> I think it's neccessary.

Ok.  Agreed.

> 
> 
> > Given that.  Why not just use -up and --down to do what's
> > needed?  Avoid changing the code and write documentation.
> 
> Agree completely. This is how I've been using OpenVPN for years
> already.

Do you have a particular config known to work with
"route-gateway dhcp"?

Do you think the distros are different enough that
separate sample config files should be supplied for each?

If documentation is all that's required perhaps the user
list should be queried to see who's already doing what
and if anybody has a starting point.


Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[Karl O. Pinc]

On 03/08/2010 09:21:35 AM, James Yonan wrote:
> OpenVPN 2.1 has a relatively recent feature that allows a TAP-based 
> OpenVPN session to be established where the client gets its IP 
> address
> 
> assignment and other attributes from the server-side DHCP server.

> I'm hoping that we can make "route-gateway dhcp" work on Unix
> platforms 
> as well.  I'm thinking there are two possible ways we could do this:
> 
> (1) Simple method: Trigger a DHCP client bind on TAP interfaces when 
> they are instantiated.  (This is what Windows does automatically)

Offhand, there seem to be various ways to go. 

A) OpenVPN restarts dhclient so that it autodetects the new interface.

B) Configure dhclient.conf with an interface directive for the
tap device.   It may be necessary to use hooks in dhclient-script.

C) A combination of A and B, where there's a separate dhclient
process run just for openvpn.  This might avoid problems with
B where the regular interfaces must also be configured because
autodetection is turned off.  It might also be more portable
across different dhcp client implimentations (or not.)

D) Use the dhcptl or omapi APIs or, perhaps even better, the omshell
command.  This would be tied to the ISC implementation,
but probably nobody cares.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] IPv6 support for TUN/TAP driver on windows

[Karl O. Pinc]

On 03/08/2010 09:16:33 AM, Samuli Seppänen wrote:
> 
> > What needs to happen next?
> >   
> >  - it whould be highly appreciated if Samuli could get OpenVPN Tech
> >to provide Windows binaries for the "openvpn-testing" tree, so
> that
> >we can get decent testing by the windows user base
> >   
> I'm on it. If this issue is not clear by Thursday, we should discuss
> it
> in the meeting.

FYI I have submitted a patch that's related.

My patch produces OpenVPN windows binaries
as part of the build process but have not yet received feedback
as to whether the project would release such binaries.

Unpackged Windows binaries? -- Problems building 2.1 rc15 on Windows XP
http://article.gmane.org/gmane.network.openvpn.devel/3171
http://thread.gmane.org/gmane.network.openvpn.devel/2566/focus=3171



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] special-case code for OpenBSD - advice needed

[Karl O. Pinc]

On 03/05/2010 10:39:26 AM, Gert Doering wrote:
> Hi,
> 
> On Fri, Mar 05, 2010 at 11:44:28AM +0100, Heiko Hund wrote:
> > On Friday 05 March 2010 10:11:51 Gert Doering wrote:
> > > What happened exactly?  Could you ask your colleague for a log
> file?
> > 
> > Well, he couldn't ping any remote host. Nothing special in the log,
> really. If 
> > it isn't misleading it's quite obvious that the ordering is wrong:
> > 
> >   TUN/TAP device /dev/tun1 opened
> >   /sbin/ifconfig tun1 destroy
> >   /sbin/ifconfig tun1 create
> >   NOTE: Tried to delete pre-existing tun/tap instance --No Problem
> if failure
> >   /sbin/ifconfig tun1 10.1.1.18 10.1.1.17 mtu 1500 netmask
> 255.255.255.255 up
> 
> Well, this is exactly what the current code for NetBSD does... (and
> how
> this thread got started).  On NetBSD, it works.
> 
> The problem is that if you do it the other way round, you have a big
> fat
> race condition here - between "I assume that my tun device will be
> tun1,
> so I do 'ifconfig tun1 destroy' now" and actually opening /dev/tun1, 
> some other process might grab this tun device.
> 
> open() first will exclusively lock it for you...

From OpenBSD's tun(4) man page:

 Each device has the exclusive open property; it cannot be 
 opened if it is
 already open and in use by another process.
 ...
 On the last close of the device, all queued packets are
 discarded.  If the device was created by opening /dev/tunN, 
 it will be
 automatically destroyed.  Devices created via ifconfig(8) are 
 only marked
 as not running and traffic will be dropped returning EHOSTDOWN.

Which means to me that you want to omit the ifconfig destroy and
create, thus:

   TUN/TAP device /dev/tun1 opened with open(2)
   /* iterate increasing tunN number until you get other than
* EBUSY (the device was already opened), or suchlike searching */
   /sbin/ifconfig tun1 10.1.1.18 10.1.1.17 mtu 1500 netmask \
  255.255.255.255 up



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Meeting topics for today

[Karl O. Pinc]

On 03/04/2010 03:18:43 AM, Samuli Seppänen wrote:
> Hi all,
> 
> here's a list of today's meeting topics:
> 
> http://www.secure-computing.net/wiki/index.php/OpenVPN/IRC_meetings/
> Topics-2010-03-04

When is the meeting?



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Erratic TCP Throughput

[Karl O. Pinc]

On 03/03/2010 02:40:16 AM, Jason Haar wrote:
> On 03/03/2010 04:52 PM, open...@rkmorris.us wrote:
> >
> > 1) Without OpenVPN - consistent performance, ~ 70 Mbps total
> > throughput (on a 100 Mb LAN).

> > 2) With OpenVPN - very consistent performance, sometimes fine, 
> other
> > times very poor. ~ 70 Mbps total throughput (on a 100 Mb LAN), but
> > bounces around a lot.

> So what you're saying is that on a ~70Mbs network you sometimes see
> ~70Mbs via "openvpn-via-proxy-server" and sometimes you don't? As the
> performance of openvpn varies - and I assume you know the client and
> server aren't the bottleneck - then that leaves?
> 
> The proxy! :-) 

Or problems with tunneling tcp inside tcp which you can trace
back via this thread:

http://article.gmane.org/gmane.network.openvpn.user/29183



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs (second round)

[Karl O. Pinc]

On 03/01/2010 08:12:03 AM, Stefan Monnier wrote:
> >> If someone could give at least some vaguely plausible scenario,
> >> that'd help.
> > Maybe there's more than one tunnel and there's some stupid
> > load balancing going on using a hosts file?  (Along with
> > deleting all non-vpn routes.)
> 
> [ Setting aside the fact that using OpenVPN's broken handling of
>   multi-FQDN to implement this is far from the only option. ]
> 
> I'm not even sure *how* this could work: how would you ensure that 
> the
> different tunnels happen to (together) route all IPs rather than all
> chosing the same IP (for example)?

I'm just waving my hands here; I'm not thinking closely about
the details and don't want to.  It sounded plausible when
it popped into my head so I sent a braindump.  I was thinking
along the lines of "well if you might want to randomize
remote endpoint choice using FQDNs resolved from a hosts file..."

Sorry if this has been more confusing than helpful.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] enhance tls-verify possibility

[Karl O. Pinc]

On 03/01/2010 04:22:04 AM, David Sommerseth wrote:
> On 01/03/10 06:32, Karl O. Pinc wrote:
> > On 02/28/2010 10:24:36 PM, Peter Stuge wrote:
> >> David Sommerseth wrote:
> >>> +++ b/options.c
> >>> @@ -529,6 +529,9 @@ static const char usage_message[] =
> >>>"  tests of certification.  cmd should return 
> 0
> >> to allow\n"
> >>>"  TLS handshake to proceed, or 1 to fail. 
> (cmd
> >> is\n"
> >>>"  executed as 'cmd certificate_depth
> >> X509_NAME_oneline')\n"
> >>> +  "--tls-export-cert [directory] : Get peer cert in PEM format
> and
> >> store it \n"
> >>> +  "  in an openvpn temporary file in 
> [directory].
> >> Peer cert is \n"
> >>> +  "  stored before tls-verify script execution
> and
> >> deleted after.\n"
> >>
> >> Please update the man page too
> >
> > There is no man page.  It's in sample-scripts/.
> >
> > However, the openvpn(8) --tls-verify section of the man page
> > is poor.  I just sent another patch that clarifies it.
> > Perhaps this is what you're looking for?  If not then
> > just ignore my man page patch.
> 
> I don't mean to be harsh ... but this patch updates options.c and
> introduces a new argument to OpenVPN.  So I agree, Peter, a man page
> update is needed!

Whoops.  I was thinking of an entirely different patch
and have been sending multiple responses that are entirely
off-topic.  *facepalm*

I agree.  Man page update is needed.


Anyhow, having written a patch to the --tls-verify
man page patch(s) someone might want to look at it
and see if the wording is better.


Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] enhance tls-verify possibility

[Karl O. Pinc]

On 02/28/2010 11:52:56 PM, Karl O. Pinc wrote:
> On 02/28/2010 11:39:11 PM, Peter Stuge wrote:
> > Karl O. Pinc wrote:
> > > > > +  "--tls-export-cert [directory] : Get peer cert in PEM
> format
> > and
> > > 
> > > There is no man page.  It's in sample-scripts/.
> > 
> > It's a new option, right?
> 
> The sample script has a new option, yes. 

Come to think of it, this is wrong.  I changed
the meaning of an existing (positional) argument.




Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

[Openvpn-devel] [PATCH] Final frobbing of openvpn(8) --tls-verify

[Karl O. Pinc]

From: Karl O. Pinc <k...@mofo.meme.com>

---
 openvpn.8 |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/openvpn.8 b/openvpn.8
index 70e1e68..51d6ac5 100644
--- a/openvpn.8
+++ b/openvpn.8
@@ -4236,7 +4236,7 @@ should return 0 to allow the TLS handshake to proceed, or 
1 to fail.
 Note that
 .B cmd
 is a command line and as such may (if enclosed in quotes) contain
-arguments separated by whitespace.  The first word of
+whitespace separated arguments.  The first word of
 .B cmd
 is the shell command to execute and the remaining words are its
 arguments.
-- 
1.5.6.5

[Openvpn-devel] [PATCH] Yet another tweak of openvpn(8) --tls-verify

[Karl O. Pinc]

From: Karl O. Pinc <k...@mofo.meme.com>

---
 openvpn.8 |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/openvpn.8 b/openvpn.8
index 9512fc3..70e1e68 100644
--- a/openvpn.8
+++ b/openvpn.8
@@ -4235,8 +4235,8 @@ should return 0 to allow the TLS handshake to proceed, or 
1 to fail.

 Note that
 .B cmd
-is a command line and as such may contain arguments separated by
-whitespace (if enclosed in quotes).  The first word of
+is a command line and as such may (if enclosed in quotes) contain
+arguments separated by whitespace.  The first word of
 .B cmd
 is the shell command to execute and the remaining words are its
 arguments.
-- 
1.5.6.5

Re: [Openvpn-devel] [PATCH] enhance tls-verify possibility

[Karl O. Pinc]

On 02/28/2010 11:39:11 PM, Peter Stuge wrote:
> Karl O. Pinc wrote:
> > > > +  "--tls-export-cert [directory] : Get peer cert in PEM format
> and
> > 
> > There is no man page.  It's in sample-scripts/.
> 
> It's a new option, right?

The sample script has a new option, yes.  But the
--tls-verify option/config file directive used
to invoke the script is unchanged.

The sample script has never had a man page.


Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] enhance tls-verify possibility

[Karl O. Pinc]

On 02/28/2010 11:32:46 PM, Karl O. Pinc wrote:

> However, the openvpn(8) --tls-verify section of the man page
> is poor.  I just sent another patch that clarifies it.
> Perhaps this is what you're looking for?  If not then
> just ignore my man page patch.

I just sent another man page patch to be applied
on top of the last one.  My git-foo is not strong
enough to be able to figure out how to send
both changes in one patch.  (Without re-checking
out the whole tree anyway.)



Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] enhance tls-verify possibility

[Karl O. Pinc]

On 02/28/2010 10:24:36 PM, Peter Stuge wrote:
> David Sommerseth wrote:
> > +++ b/options.c
> > @@ -529,6 +529,9 @@ static const char usage_message[] =
> >"  tests of certification.  cmd should return 0
> to allow\n"
> >"  TLS handshake to proceed, or 1 to fail.  (cmd
> is\n"
> >"  executed as 'cmd certificate_depth
> X509_NAME_oneline')\n"
> > +  "--tls-export-cert [directory] : Get peer cert in PEM format and
> store it \n"
> > +  "  in an openvpn temporary file in [directory].
> Peer cert is \n"
> > +  "  stored before tls-verify script execution and
> deleted after.\n"
> 
> Please update the man page too

There is no man page.  It's in sample-scripts/.

However, the openvpn(8) --tls-verify section of the man page
is poor.  I just sent another patch that clarifies it.
Perhaps this is what you're looking for?  If not then
just ignore my man page patch.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

[Openvpn-devel] [PATCH] Frob the openvpn(8) man page tls-verify section to clarify

[Karl O. Pinc]

From: Karl O. Pinc <k...@mofo.meme.com>

---
 openvpn.8 |   22 +-
 1 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/openvpn.8 b/openvpn.8
index f1612a7..0150ba7 100644
--- a/openvpn.8
+++ b/openvpn.8
@@ -4232,11 +4232,23 @@ test).

 .B cmd
 should return 0 to allow the TLS handshake to proceed, or 1 to fail.
+
+Note that
+.B cmd
+may contain whitespace (if enclosed in quotes), in which case the first
+word of
+.B cmd
+is the shell command to execute and the remaining words are its
+arguments.
+When
 .B cmd
-is executed as
+is executed it is passed two (additional) arguments, as follows:

 .B cmd certificate_depth X509_NAME_oneline

+These arguments are, respectively, the current certificate depth and
+the X509 common name (cn) of the peer.
+
 This feature is useful if the peer you want to trust has a certificate
 which was signed by a certificate authority who also signed many
 other certificates, where you don't necessarily want to trust all of them,
@@ -4250,14 +4262,6 @@ in the OpenVPN distribution.

 See the "Environmental Variables" section below for
 additional parameters passed as environmental variables.
-
-Note that
-.B cmd
-can be a shell command with multiple arguments, in which
-case all OpenVPN-generated arguments will be appended
-to
-.B cmd
-to build a command line which will be passed to the script.
 .\"*
 .TP
 .B --tls-remote name
-- 
1.5.6.5

Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs (second round)

[Karl O. Pinc]

On 02/28/2010 02:04:01 PM, Stefan Monnier wrote:

> 
> I'm at a loss when it comes to try and imagine someone who's used to
> the
> current behavior and bothered by the new behavior.  Really.  How can
> the
> current behavior ever be preferable?  Why would someone ever prefer
> that
> a route would be randomly chosen to either go through the VPN or not.
> 
> I haven't heard any such someone raise her voice, and neither have
> I heard anyone come up with a scenario where such a someone could
> exist.
> 
> If someone could give at least some vaguely plausible scenario,
> that'd help.

Maybe there's more than one tunnel and there's some stupid
load balancing going on using a hosts file?  (Along with
deleting all non-vpn routes.)

??

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] special-case code for OpenBSD - advice needed

[Karl O. Pinc]

On 02/28/2010 08:50:01 AM, Gert Doering wrote:
> Hi,
> 
> while working on "make IPv6 payload work on Win32", I found something
> quite peculiar for OpenBSD in the OpenVPN code.


> 
> Now, for all operatings systems *except* Win32 and OpenBSD, the
> sequence
> of execution is
> 
>  open_tun()
>  do_ifconfig()
> 
> and for the named two systems, it's 
> 
>  do_ifconfig()
>  open_tun()


> Question #1: why is OpenBSD treated differently?  Does anyone on this
> list 
> know why this is so, and whether it needs to be kept that way?  (I
> have no 
> OpenBSD system to test on, right now).

Random comments

On OpenBSD 4.6 stable "man 4 tun" says:


 A tun interface can be created at runtime using the ifconfig tunN 
create
 command or by opening the character special device /dev/tunN.

 Both layer 3 and layer 2 tunneling is supported.  Layer 3 
tunneling is
 the default mode; to enable layer 2 tunneling mode the link0 flag 
needs
 to be set with ifconfig(8), or by setting up a hostname.if(5) 
configura-
 tion file for netstart(8).  In layer 2 mode the tun interface is 
simulat-
 ing an Ethernet network interface.


So, you should not need to do the ifconfig at all unless you're
interested in tap functionality or there's other odd
frobbing going on.

I can't speak for older releases but all the old man pages are
on the OpenBSD.org site.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] OpenVPN Pf plugin/small status patch

[Karl O. Pinc]

On 02/28/2010 07:22:16 AM, David Sommerseth wrote:
> On 26/06/09 17:00, Arne Schwabe wrote:
> > Hi,
> >
> > I have written a simple plugin for packet filtering that looks up 
> fw
> rules
> > in the order
> >
> > Commonname.pf
> > IP_Port.pf
> > IP.pf
> > default.pf
> >
> > If one of this files is found the file is used as PF configuration.
> Maybe
> > this plugin is useful for someone else.
> 
> Hi!
> 
> Thank you for your patches.  I've been looking at both patches, and I
> have some questions in regards to this plug-in.

I think that a vocabulary change could help avoid confusion, depending
on exactly what the proposed vocabulary is here.  "pf" is the offical
name for the OpenBSD packet filter.  IIRC it is also ported to FreeBSD
and perhaps elsewhere.  Using the name "pf" for this plugin could
be confusing.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH v2] Do not randomize resolving of IP addresses in getaddr()

[Karl O. Pinc]

On 02/22/2010 03:46:33 PM, David Sommerseth wrote:


> 
> Does that cover your concerns?

Yes.  It's all somewhat a matter of taste, so if you
find it tasty that's good enough for me.  :-)



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH v2] Do not randomize resolving of IP addresses in getaddr()

[Karl O. Pinc]

On 02/22/2010 10:52:17 AM, Peter Stuge wrote:
> Karl O. Pinc wrote:
> > Someone may be relying on the behavior but, at the moment
> > or depending on present dns circumstances, does not have
> > multiple A records returned.  In this case no warning will
> > be generated.
> 
> The flip side of that coin is also valid I think.
> 
> Consider independent configuration of VPN and DNS. Early errors would
> restrict VPN setup and possibly shipment until after DNS has been set
> up, while lazy evaluation allows DNS changes to happen later.

Right, but there's nothing to "restrict" because in this case we're
talking about a warning not an error; generating a warning that default
behavior will change in a future release.  OpenVPN _should_ 
continue happily along its way no matter where
the warning is generated.

It's a pretty trivial point really, but may provide a template
for future changes.

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH v2] Do not randomize resolving of IP addresses in getaddr()

[Karl O. Pinc]

On 02/19/2010 05:11:38 PM, David Sommerseth wrote:
> On 20/02/10 00:06, Karl O. Pinc wrote:
> > On 02/19/2010 04:57:30 PM, David Sommerseth wrote:
> >
> > Am I wrong or does using --disable-depr-random-resolv
> > not remove the random choice?
> 
> That is correct.  According to the newly agreed feature removal
> process,
> deprecated features should in the beginning be enabled but give
> warnings
> when they are triggered.  At some point, this behaviour will be
> switched
> to be disabled, and you need to do use --enable-depr-random-resolv.

Irrespective of the actual change being made here, does it
make sense to have a "next release" branch?

If changes to defaults/depreciation of features is to happen
at major release number boundaries, or whatever defined point,
it is important not to "miss" making such a planned change
happen in the first version of the new major release.
Likewise, having to go back and re-visit the code to 
make the actual change could be error prone.  And we
would not want these changes to conflict with any other
changes either.

Having another branch to track changes that will happen
in the next major release solves all of these problems.
This branch would have the code that by default changes
the existing behavior, enables the new feature, etc.

Just a thought.

Regards,

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH v2] Do not randomize resolving of IP addresses in getaddr()

[Karl O. Pinc]

On 02/22/2010 01:46:53 AM, David Sommerseth wrote:

  The commit log 
> will
> state that this begins the feature deprecation process, with a 
> warning
> when this feature is used and the feature can be removed at compile
> time
> with --disable-depr-random-resolv.

I've thought a bit more about this.  It seems to me that the
warning message happens at the wrong time.  In your patch
(IIRC) it happens at dns resolve time, only when there are multiple
A records returned.  It should happen at OpenVPN startup
time for the following reasons:

Someone may be relying on the behavior but, at the moment
or depending on present dns circumstances, does not have
multiple A records returned.  In this case no warning will
be generated.

Generating a message every time dns lookup is done
could result in "too many" messages, increasing the
log files and filling somebody's disk.  (Unlikely, but...)
In any case it adds additional noise in which
legitimate messages could be lost.

Arguably, a message sent at startup time is more
likely to be noticed than one buried amid others
that occur over time.

Generating one message at startup time is "least
invasive" to the code.  Everybody will
execute the code path and so (in the unlikely
event) any bugs will be found and fixed early.
Likewise, any introduced problem will occur during
initialization rather than "runtime" and so will
happen at a predictable point.
The code that actually "does something" will be
untouched, removing any possibility of race
conditions or anything else that might interfere
with actual operation.

In the general case I would think you'd want
warnings regarding features chosen/not chosen/
depreciated/etc. to be generated at config
parse time.

/brain dump

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH v2] Do not randomize resolving of IP addresses in getaddr()

[Karl O. Pinc]

On 02/19/2010 05:11:38 PM, David Sommerseth wrote:
> On 20/02/10 00:06, Karl O. Pinc wrote:
> > On 02/19/2010 04:57:30 PM, David Sommerseth wrote:
> >
> > Am I wrong or does using --disable-depr-random-resolv
> > not remove the random choice?
> 
> That is correct.  According to the newly agreed feature removal
> process,
> deprecated features should in the beginning be enabled but give
> warnings
> when they are triggered.  At some point, this behaviour will be
> switched
> to be disabled, and you need to do use --enable-depr-random-resolv.
> And if nobody complains in the end, this code will be removed
> completely.

I understand the point of the policy, but it seems a bit crazy
to ask for the feature to be disabled and have it _not_ be disabled
but to get a warning instead.  

What you have right now is (unless I mis-understand the code):

Regardless of whether you ask for the feature to be disabled
or not the feature remains _enabled_ and you get a
runtime warning.

If you ask for the feature to be enabled you get no warning.


What makes sense to me is:

By default the feature remains enabled but there _is_ a 
runtime warning.

If you explicitly ask for the feature to be disabled then it
is disabled and there is _no_ runtime warning.

If you explicitly ask for the feature to be enabled then
it is enabled and there is _no_ runtime warning.


This trinary choice conforms to the policy whereby
depreciated features remain _by_ _default_ enabled but 
generate warnings.  However it also allows those
who make explicit choices to choose desired functionality,
which not-incidentally allows those who wish a change in 
functionality to test out how the change works.  And it
recognizes that those who make explicit choices are aware
of what those choices do and so do not need warnings.
Especially because anyone who makes an explicit choice
from this point forward will get the requested feature
and does not care about the default
because they are not using the default.

If someone who explicitly chooses a functionality
needs to get a warning about the default they
should get this warning at ./configure time --
the time they make the choice.  Not at runtime.
(Of course those who rely on the default should,
IMO, get a runtime warning message because most of these
people won't be doing the ./configure step.)

Whatdayathink?


Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs

[Karl O. Pinc]

On 02/19/2010 03:02:40 AM, David Sommerseth wrote:
> On 19/02/10 04:18, Stefan Monnier wrote:

> >
> > If it's a config var, it could indeed just be a global var, so I
> don't
> > think it would be very complex.  But that's really not something 
> the
> > user should have to configure.
> 
> That depends on the solution we end up with.

What do you mean "configure"?

This is exactly the sort of thing that a 

./configure --connection-limit=20

sort of configuration setting is good for.  Someone
might want to frob it, but does it need to be dynamically
configurable in the openvpn config file?  If you make
the default large enough for anybody then the embedded systems
people can reconfigure their binary to shrink it need be.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Summary of the IRC meeting (18th Feb 2010)

[Karl O. Pinc]

On 02/19/2010 06:48:44 AM, Samuli Seppänen wrote:

> Btw. what do you think about including the full IRC chatlog in these
> emails? 

I like it.  (And don't see the point in having a separate attachment
either.  It's just one more thing to have to click on.)


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs

[Karl O. Pinc]

On 02/18/2010 12:26:37 PM, Karl O. Pinc wrote:

> (I seem to recall that bind attempts to rotate the ordering
> of the names, but I can't find any reference to this at a glance
> and could be wrong.)  

Ah, here it is.  Bind9 has a rrset-order directive.  Results can
be fixed, random, or cyclic but fixed is disabled and must be
enabled by compilation directive.

So, unless you're pulling names out of /etc/hosts it's likely
that randomization does nothing.  And if the bind administrator
has gone to the extra work to enable a fixed ordering of
RR records then randomization destroys his work.

The only thing randomization would be good for is when
pulling names out of a hosts file, and even then I'd want
to leave the job to the resolver.  If it's important
to randomize hosts entries then IMO there should
be something in the config file to enable randomization,
and that is probably solving the wrong problem.

Regards,

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs

[Karl O. Pinc]

On 02/18/2010 08:12:17 AM, David Sommerseth wrote:
> On 18/02/10 13:53, Gert Doering wrote:

> >> * usage of get_random in getaddr() [socket.c:261]
> >>
> >> I admit I should have spotted this one on the first review. 
> Because
> >> this code snippet below looks really odd to me.
> >>
> >>   if (nb > 1)
> >> {
> >>   msg (D_RESOLVE_ERRORS, "RESOLVE: NOTE: %s resolves to %d
> >>  addresses, choosing one at random",
> >>   hostname,
> >>   nb);
> >>   return ips[get_random () % nb];
> >> }
> >>
> >>
> >> Why on earth do you want to use get_random() in this situation?
> >
> > That's original OpenVPN code, just moved to a different place.
> 
> > While I am not saying that it should be that way, or should not be
> that
> > way, it's not something brought in by the patch in question, so
> should
> > not be covered by its review.
> 
> Agreed.  Lets hear with James today if he see any reasons for using
> get_random() in this situation.  It really do not see any advantage 
> of
> this at all.

FWIW RFC 1034 (DOMAIN NAMES - CONCEPTS AND FACILITIES
http://www.rfc-editor.org/rfc/rfc1034.txt) seems to imply that
this sort of munging is appropriate in a resolver.  In any
case the ordering of the results when multiple A records are
returned seems to be entirely up to the DNS implementation.
(I seem to recall that bind attempts to rotate the ordering
of the names, but I can't find any reference to this at a glance
and could be wrong.)  The choice to randomize seems wrong
because it will destroy anything "smart" that the resolver
might do.


5.2. Client-resolver interface

5.2.1. Typical functions

The client interface to the resolver is influenced by the local host's
conventions, but the typical resolver-client interface has three
functions:

   1. Host name to host address translation.

  This function is often defined to mimic a previous HOSTS.TXT
  based function.  Given a character string, the caller wants
  one or more 32 bit IP addresses.  Under the DNS, it
  translates into a request for type A RRs.  Since the DNS does
  not preserve the order of RRs, this function may choose to
  sort the returned addresses or select the "best" address if
  the service returns only one choice to the client.  Note that
  a multiple address return is recommended, but a single
  address may be the only way to emulate prior HOSTS.TXT
  services.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

[Openvpn-devel] [PATCH] Change verify-cn so cn is no longer hardcoded in openvpn's config file

[Karl O. Pinc]

---
 sample-scripts/verify-cn |   42 +++---
 1 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/sample-scripts/verify-cn b/sample-scripts/verify-cn
index 5d56d95..f9fea0f 100755
--- a/sample-scripts/verify-cn
+++ b/sample-scripts/verify-cn
@@ -7,24 +7,28 @@
 #
 # For example in OpenVPN, you could use the directive:
 #
-#   tls-verify "./verify-cn Test-Client"
+#   tls-verify "./verify-cn /etc/openvpn/allowed_clients"
 #
 # This would cause the connection to be dropped unless
-# the client common name is "Test-Client"
+# the client common name is listed on a line in the
+# allowed_clients file.

-die "usage: verify-cn cn certificate_depth X509_NAME_oneline" if (@ARGV != 3);
+die "usage: verify-cn cnfile certificate_depth X509_NAME_oneline" if (@ARGV != 
3);

 # Parse out arguments:
-#   cn-- The common name which the client is required to have,
-#taken from the argument to the tls-verify directive
-#in the OpenVPN config file.
-#   depth -- The current certificate chain depth.  In a typical
-#bi-level chain, the root certificate will be at level
-#1 and the client certificate will be at level 0.
-#This script will be called separately for each level.
-#   x509  -- the X509 subject string as extracted by OpenVPN from
-#the client's provided certificate.
-($cn, $depth, $x509) = @ARGV;
+#   cnfile -- The file containing the list of common names, one per
+# line, which the client is required to have,
+# taken from the argument to the tls-verify directive
+# in the OpenVPN config file.
+# The file can have blank lines and comment lines that begin
+# with the # character.
+#   depth  -- The current certificate chain depth.  In a typical
+# bi-level chain, the root certificate will be at level
+# 1 and the client certificate will be at level 0.
+# This script will be called separately for each level.
+#   x509   -- the X509 subject string as extracted by OpenVPN from
+# the client's provided certificate.
+($cnfile, $depth, $x509) = @ARGV;

 if ($depth == 0) {
 # If depth is zero, we know that this is the final
@@ -34,11 +38,19 @@ if ($depth == 0) {
 # the X509 subject string.

 if ($x509 =~ /\/CN=([^\/]+)/) {
+$cn = $1;
# Accept the connection if the X509 common name
# string matches the passed cn argument.
-   if ($cn eq $1) {
-   exit 0;
+   open(FH, '<', $cnfile) or exit 1; # can't open, nobody authenticates!
+while (defined($line = )) {
+   if ($line !~ /^[[:space:]]*(#|$)/o) {
+   chop($line);
+   if ($line eq $cn) {
+   exit 0;
+   }
+   }
}
+   close(FH);
 }

 # Authentication failed -- Either we could not parse
-- 
1.5.6.5

[Openvpn-devel] Make sample-scripts/verify-cn dynamic

[Karl O. Pinc]

Hi,

Re: [PATCH] Change verify-cn so cn is no longer hardcoded in openvpn's config 
file

This patch should be easy to process.
A resubmission of the patch sent to this list on 04/23/2009.

The patch changes the verify-cn script sample
to be used with --tls-verify so that instead of having
to hardcode a cn to verify in the OpenVPN configuration file
the allowed cns may be written into a separate file.

This makes the process of verifying cns a whole
lot more dynamic, to the point where it is useful
in the real world.

One problem with this patch is that it is backwards
incompatible.  I did not bother keeping the original
calling interface as A) it's a sample script, and B) the
original's functionality seems useless
and equalivant functionality is easily available
with the new script.

The problem with the original is that there seems
little point in verifying a client's cn when all
the clients share one cn, as would have to be
the case when the cn is hardcoded into the openvpn
config file.

This patch applies against the testing allmiscs branch,
and should apply against any of the other testing
branches as well.

It works for me.  I've tested it throughly but not
used it extensively in production.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Summary of the IRC meeting (4th Feb 2010)

[Karl O. Pinc]

On 02/05/2010 07:01:14 AM, Samuli Seppänen wrote:
> Here's a summary of yesterday's meeting. This and earlier meeting
> summaries are linked to from here:
> 
> http://www.secure-computing.net/wiki/index.php/OpenVPN/IRC_meetings

The link there seems to refer back to your email, which does not
contain a summary of the IRC meeting.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Summary of the IRC meeting (28th Jan 2010)

[Karl O. Pinc]

On 01/31/2010 11:13:06 AM, Eric F Crist wrote:
> I do not feel the forums and mailing list need to be synchronized. 
> They are two different mediums, and should be treated as such. 

I disagree.  (Although this has no impact on any operational decision
because so far as I know there's no good choice of software.
Maybe mailman 3.0 will someday deliver.)

Forms and archived mailing lists are the exact same medium.  They may 
happen to have different interfaces for input and output, but the 
interfaces are in no way mutually exclusive.  The end result is a 
threaded archive viewable on the web in either case.

If you've software that allows input via web page and/or email
and output via web interface and/or email is it a forum or a mailing
list?  It's both.  My point being it's then really silly to have
2 different archives depending on whether the data went in or out via
an email or a web page.

There should be only one place to look for archived answers no
matter how the questions are asked and answers supplied.  To
do otherwise leads to duplication of effort and difficulty in
searching.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Summary of the "OpenVPN development model" meeting

[Karl O. Pinc]

On 01/27/2010 07:28:24 PM, Peter Stuge wrote:
> David Sommerseth wrote:
> > For those of us not being heavily involved in development processes
> > from day-to-day, we can probably survive with whatever VCS is being
> > used.
> 
> Fair enough. But I think two git features in particular matter also
> in the casual patcher case. It's very nice that git keeps both author
> and committer information, and it's doubleplus nice that git can
> transport commits via email. These two in particular allow regular
> developers to accept casual patches very easily.

The general case is that people maintaining their own trees benefit
from a distributed revision control system.  These people might not
be the same people who are heavily developing the official version,
but might be people who need their own patches for whatever reason.

A distributed VCS allows _everybody_ to have a VCS and benefit
therefrom, not just the OpenVPN developers themselves.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] win32 openvpn-2.1.1 has bug with "nobind"?

[Karl O. Pinc]

On 01/25/2010 05:26:13 PM, Jason Haar wrote:

> In general it works well, but once in a while, restarting openvpn
> doesn't work - you get some vague "cannot access" error. Waiting some
> minutes or rebooting will always fix the problem. Ends up that 
> running
> "netstat -an" in this situation shows that something is associated
> with
> udp port 1194 - svchosts.exe. When this happens, waiting until 1194
> disappears from netstat means I'm able to start openvpn successfully.


Sounds like the 2MSL problem described in this thread:
http://sourceforge.net/mailarchive/forum.php?thread_name=1263527105.29484.1%40mofo_name=openvpn-devel


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] RFE: allow 'lport 0' setup for random port binding

[Karl O. Pinc]

On 01/11/2010 08:31:01 AM, Enrico Scholz wrote:

> 
> no; it is because the OpenVPN client creates the same src + dst pair
> for every connection.  I suggest to read some papers about stateful
> firewalls before continuing this discussion.

Enrico is right.  It's in the IP RFC, the 2MSL (twice the maximum
segment lifetime) rule.  (STD 5 is the right rfc?)

I haven't otherwise been following the discussion, but if there's
no other way to do what he wants to do with OpenVPN then
OpenVPN is violating the RFC.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] IRC meeting regarding OpenVPN development model

[Karl O. Pinc]

On 01/06/2010 09:14:01 AM, Eric F Crist wrote:

> This forum will be moderated.  To apply for +v during the
> conversation, please send an email to open...@secure-computing.net
> with your registered IRC nickname and reason for requesting +v.

That sounds less than open and engaged with the community.  
Wouldn't it be better to simply
ban people if there is a problem? (If you have enough
attendees you'll have to resort to that strategy anyway.)

There are irc channels with plenty of attendees (#debian
on freenode has 946 as I write) and they manage to keep
the conversation civil(ish), on-topic, and productive.

Isn't "I might want to contribute something." reason enough
to ask for +v?  If so then would seem to be no point
in asking for pre-registration. it would simply be a way 
to reduce the number of contributing attendees.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Character classes in the tls-verify script

[Karl O. Pinc]

On 11/13/2009 07:05:37 AM, David Sommerseth wrote:

> When a broad part of the users have tested this over time, used it in
> production environment and bugs connected to this is fixed ... then 
> we
> can consider to change the default behaviour, which normally would be
> done in connection to a new major release.  

I agree that changes that break backwards compatibility should be
what triggers a change in the major release number.  But,
and I may be wrong here, I don't believe that OpenVPN has
adopted the practice -- in which case it makes little sense
to have a change in a major release number be the deciding
factor.

Your argument that the patch is not well enough tested
is enough to make me agree that the default should not
be changed now. 


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Character classes in the tls-verify script

[Karl O. Pinc]

On 11/13/2009 06:28:36 AM, Victor Wagner wrote:

> It is possible to add ADDITIONAL configuration directive such as
> --allow-unicode-in-names, which doesn't  have such side-effect as
> no-name-remapping
> does now.
> 
> But I think that this should be enabled by default. If someone cannot
> handle normal letters, he can disable them.

This makes sense.

But...

I am not very familiar with localization but there surely
must be commonly accepted idioms with respect to defaults
such as this and the locale settings.  Without knowing
anything about it my suggestion would be to enable
multi-byte characters by default _unless_ the locale
is C.  (Perhaps this is exactly what the locale settings
are supposed to be about?)

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Script interface to trigger events depending on the validity of a certificate

[Karl O. Pinc]

On 11/11/2009 06:26:04 AM, David Sommerseth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 11/11/09 12:06, Mathieu GIANNECCHINI wrote:
> > Victor Wagner a écrit :

> >> But if entire certificate would be available, it would be possible
> to
> >> extract any information from it (or hash it with any algorithm)
> from the
> >> script using openssl command line utility or some binding or
> OpenSSL
> >> libraries to the choosen script language.

> Indeed!  And you're about to get my vote for this implementation ...
> but
> I have two concerns.

> 2) If an attacker sends a certificate with his certificate and 999 CA
> certificates in a chain, what will happen?  What happens if the disk
> goes full or the certificate cannot be written?

You're a lot less likely to fill the disk than you are to run out
of RAM.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] How to check is OpenVPN port is open

[Karl O. Pinc]

On 10/28/2009 02:24:12 PM, Lucas Mocellin wrote:
> Hi all,
> 
> briefly: I'm helping in the development of an educational software to
> apply
> online tests. The client will connect to the server through OpenVPN 
> to
> perform the test. I would like to check if the OpenVPN port is alive
> and
> accepting connections (check if there is port filtering, and so on..
> ).
> 
> I'm programming in python.
> 
> Does someone know to achieve that? I'm trying to create a socket and
> send
> any message to the server, but no response, is there any kind of
> "hello" or
> something like this?

You could re-implement the beginning of the connection but why
not simply use the subprocess module to run openvpn?  You can
see if it succeeds and if not you can capture output and have a
real log from which the user (broadly speaking) can diagnose
the problem.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] FQDN for routes should expand to all IPs

[Karl O. Pinc]

On 10/24/2009 02:45:04 PM, James Yonan wrote:

> Having said that, your bug report seems more like a feature request 
> since routing commands/APIs generally do not support DNS A-record 
> expansion as a standard feature.

My favorite firewall/packet redirector, pf, does.  (It runs on the
BSDS.)  I find that using DNS names makes configuration files
very, very, much more readable.

Of course care is required to ensure that the names
will resolve whenever required.  The basic trick is to run
a slave nameserver for those zones you care about on the
firewall/router, be sure that the slave server expiration 
is "long enough", and never use dns names that are not
resolvable by the local namserver.   So long as your
nameserver is working you have config files that are
human readable -- a trade off I find well worth it.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Losing connectivity when OpenVPN cannot establish tunnel under Windows

[Karl O. Pinc]

On 09/02/2009 09:39:52 PM, John Cullison wrote:

FWIW, I'm not a developer and may or may not have
useful info.  I'm just asking the questions I would
look into.  At some point I'll likely run out of
questions.

  Ping is not a valid test for
> us,
> as at least one of our firewalls blocks ICMP.

You could use a udp ping or something like telnet to port 80
just to keep the complication minimal, but you know your network best.

> 
> I just ran ipconfig (it's like ifconfig, only for Windows) on my test
> XP
> box before and after the problem occurs, and the Default Gateway has
> indeed gone missing:

The next question is: Is the default gateway being configured
via DHCP options that are coming from OpenVPN or is there some
other reason why the default gateway is altered?  Is it the
local openvpn that's supposed to alter the gateway, the remote
end, or neither?  Your local and remote configs would help here.

> 
> So I guess I can stop giving my guess as to what's going on and
> declare
> explicitly that something about OpenVPN is clobbering my default
> gateway
> setting when it cannot open a tunnel a second time.

Was there no OpenVPN on the other end both tests?  Does
it take 2 failed connection attempts to exhibit the
problem or just failure when there's no answer?





Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] OpenVPN with LDAP+TLS authentication runs into file exhaustion

[Karl O. Pinc]

On 08/26/2009 05:56:22 AM, chantra wrote:
> Hi all,
> 
> 
> This issue is happening on both :
> * debian etch   openvpn 2.0.9-4etch1  libpam-ldap 180-1.7
> * debian lenny openvpn 2.1~rc11-1  libpam-ldap 184-4.2

FWIW,

You could also try filing a bug report with debian,
just to get more people looking at the problem.
They might be able to come up with a patch that could
be pushed upstream.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] OpenVPN 2.1_rc19 released

[Karl O. Pinc]

On 07/28/2009 11:47:57 PM, Alon Bar-Lev wrote:
> Well,
> I do not understand you guys.
> 
> If you think SELinux is so great, why do you need chroot?
> It is like you put some money in safe, and then put the safe into
> another safe, it never ends... Why only two safe, let's put another
> safe...
> I know that this is the approach many of security advisors use, but I
> never could have found the logic.
> If you want to keep your money safe use a single safe and select the
> strongest one.

The idea is more like selecting the strongest safe, then putting
it behind a moat inside a ring of fire.  That way the thief not
only has to be a good safe cracker, he must also be
a fire walker and a swimmer, with experience wrestling
alligators a decided advantage.  Multiple layers of _different_
security raises the bar considerably.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] OpenVPN 2.1_rc19 released

[Karl O. Pinc]

On 07/28/2009 04:22:09 PM, Sebastien Raveau wrote:


> If I understand you correctly, that is, if you are suggesting that
> OpenVPN should automatically apply a SELinux context if setcon() is
> available... I'll have to disagree with you. Not that I reject the
> idea of enforcing security measures by default, but because when you
> google for "selinux howto", half of the first-page results are on how
> to *disable* SELinux. Apparently not everybody likes it, and they 
> have
> a right to, so I believe we should not force it upon them :-)

SELinux is a great idea, in theory.  In practice I find the
cost/benefit such that I wind up turning it off.  I'd love
to have it available and working in "stock" situations,
and have the (easy to do) option of turning it off if
desired.   If nothing else it gets in the way of development/
deployment.  After something's working then it's possible to go back
and figure out which permissions need enabling.

Because of the complication it would also be highly
desirable, except for a possible "off/monitor mode/on"
switch, if it would integrate with the rest of SELinux
so there's not yet more configuration.  I assume that
this is the natural approach to take, but figured I'd
mention it anyway.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] OpenVPN 2.1_rc19 released

[Karl O. Pinc]

On 07/16/2009 04:24:44 PM, James Yonan wrote:

Matthias Andree wrote:
> James Yonan schrieb:
>
>> 2009.07.16 -- Version 2.1_rc19
> ...
>
>> * In configure.ac, use datadir instead of datarootdir for
compatibility
>>with 
> Dear Jim,
>
> This is backwards.  Please don't do that,




We need to be able to build OpenVPN on older Linux distros, such as
RHEL
4, that use pre-2.60 versions of autoconf.


I don't know about earlier, but autoconf 2.59 comes with

# m4_version_prereq(VERSION, [IF-OK], [IF-NOT = FAIL])
# 
# Check this Autoconf version against VERSION.

AFICT this can be used to do things one way with older
versions and another with newer.

m4_version_preqreq(`2.60', datarootdir, datadir)

I can't say whether this is actually a better way
to do things.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Loss of routes causes routing loop

[Karl O. Pinc]

On 06/04/2009 04:13:18 PM, Daniel Johnson wrote:


On a related note, I'm looking at adding a second interface on the two
main (and now only) VPN servers, so that they'll be 'local' on the
guest/wireless network.  Does OpenVPN do anything special with DNS
results to prefer local addresses?  If not, can that be added easily?


Openvpn does not do DNS at all.  You can use it to push DNS related
DHCP options to the "clients" so that they are directed to a DNS
server that does the right thing.  (There may be a way to
do something similar in a "client-side" config, I don't recall.)
That's about it.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] Reporting issue with v2.1 rc16 and --cryptoapicert

[Karl O. Pinc]

On 05/30/2009 05:30:09 AM, James Yonan wrote:

I would rather not have touched cryptoapi.c for rc16, but it wouldn't
build with MinGW 5.1.4 (the .h files in this version of MinGW define
the
symbol CryptAcquireCertificatePrivateKey which conflicts with the
symbol
of the same definition in cryptoapi.c).  So I did try to work around
the
issue, but perhaps I broke something in the process.

It would be great if one of the developers that uses the crypto API
feature could take a look at it.  We will certainly accept a patch
that
fixes any introduced breakage.


From my post:
http://sourceforge.net/mailarchive/message.php?msg_name=1239152310l.18482l.7l%40mofo


One issue is that cryptoapi.c works around a
problem where CryptAcquireCertificatePrivateKey
is missing from MinGW.  However, I've installed
the latest stable MinGW, 5.1.4, and the function
is now in MinGW.  So, I tried commenting out the
#ifdef __MINGW32_VERSION hacks in cryptoapi.c.
This seems to have worked.  (So far)


The above works.  In other words there's a bunch
of extra code in cryptoapi.c that no longer needs
to be there, at least with the latest MinGW.
To retain compatibility with older MinGW versions
the right thing to do is conditional compilation
based on the MinGW version, or maybe there's another
approach that would work better.  I've not looked
at the code in a while.

Back when I was looking at getting OpenVPN
to compile under MinGW I might have sent a patch
to this list but
I've already sent 3 patches and gotten no feedback
whatsoever from anybody who seems to be a
maintainer so I don't really see the point in
trying to contribute.




James

Alon Bar-Lev wrote:
> True.
> I already reported this to James.
> There were too many change-replace at the cryptoapi.c in this
version.
>
> On Fri, May 29, 2009 at 2:09 PM, Markus Bickel
 wrote:
>> Dear developers,
>>
>> I'm currently installing and testing OpenVPN 2.1 on windows
environment and have seen that there's a newer version rc16.
>>
>> Since this version I cannot use the parameter:
>>
>> --cryptoapicert "Thumb:xx xx xx xx xx"
>>
>> Error message:
>>
>> cannot load certificate "Thumb:xx xx xx xx  " from Microsoft
Certificate Store:
>> error:C506C064:microsoft cryptoapi:GetProcAddress:The specified
procedure could not be found.
>>
>>
>> This behaviour is the same on server or client sides.
>> With rc15 this worked well.
>>
>> Maybe this is a small bug.
>> So I want to report this issue to you.
>>
>> Would it be fixed in rc17?
>>
>> Thanks in Adanvce,
>>
>> Markus
>>
>> --
>> Nur bis 31.05.: GMX FreeDSL Komplettanschluss mit DSL 6.000
Flatrate und
>> Telefonanschluss nur 17,95 Euro/mtl.!*
http://portal.gmx.net/de/go/dsl02
>>
>>  
--

>> Register Now for Creativity and Technology (CaT), June 3rd, NYC.
CaT
>> is a gathering of tech-side developers & brand creativity
professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity,
Processing, &
>> iPhoneDevCamp as they present alongside digital heavyweights like
Barbarian
>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>
>
>  
--

> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT

> is a gathering of tech-side developers & brand creativity
professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing,
&
> iPhoneDevCamp as they present alongside digital heavyweights like
Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity
professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &

iPhoneDevCamp as they present alongside digital heavyweights like
Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel





Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] OpenVPN 2.1_rc16 released

[Karl O. Pinc]

On 05/21/2009 01:51:36 AM, Alon Bar-Lev wrote:

On 5/21/09, Felix Kronlage  wrote:
> On Wed, May 20, 2009 at 11:39:57AM +0200, Matthias Andree wrote:
>
>  > + release openvpn 2.1 without Windows GUI as soon as you believe
it's done
>  >* your changelog below suggests that RC16 needs more than just
>  >  a week of testing
>  > + stabilize (through beta and RC) the Windows GUI as a separate
add-on
>  >   package (if you want, these test releases can then comprise
2.1_rc,
>  >   2.1.0, 2.1.1, ... whichever is current, for user convenience)
>
>
> ack.
>  Small and fast release cycles. At least 'fast' compared to now
would
>  be nice.

Yes...
OpenVPN has several separate components, each can be released
separately:




It would be much easier if every component has its own version and
dependency.


This makes sense to me.

I'm putting in a vote for releasing as-is (ish) and not making
any major changes until the next release.  I've put a lot of time
into working with rc15 in the expectation that there won't be much
in the way of changes for the final 2.1 release.  It seems
reasonable to expect major changes on release boundaries.
Violating that expectation would, at minimum, keep me away
from rc releases.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] linux openvpn development job

[Karl O. Pinc]

On 04/28/2009 02:40:43 PM, Siim Põder wrote:


Yes, I was still talking about additional boxes. HW encryption (as i
see
it) will not help at all, because by the current design, all packets
need to come to userland and go back to kernelland. Most likely to
talk
to the HW encryption device, another round-trip to kernel space would
be
needed?


That's what I'm guessing happens in my rudimentary testing.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] linux openvpn development job

[Karl O. Pinc]

On 04/27/2009 03:45:58 AM, Benny Amorsen wrote:



It seems that OpenVPN is quite far away from the theoretical
performance
where kernel-userspace-kernel copying becomes an issue. Right now
encryption is quite expensive, except on a few platforms with
dedicated
AES instructions.


Dedicated encryption hardware is cheap. (<$100) And it seems
that using it can also involve a kernel/userspace
transition.

I've a box with an AMD Geode LX.  This chip supports
AES-128 bit encryption.  The same box also has a Hi/fn 7955
chip on a separate PCI card, which supports AES-256
as well as other algorithms.

When I switch from AES-128 to AES-256, or other, cheaper,
choices supported by the Hifn but not the Geode,
I see a large performance hit.  Assuming my tests
are right; I've not put a lot of effort into it.

I suspect the problem is again kernel/userspace.
The CPU is available to userspace, but the Hifn
is not.  (There are other possibilities.  Perhaps
OpenSSL does not play well with multiple hardware
accelerators, or maybe my tests are just plain bad.)

So, I believe it's easy and cheap to add hardware
to a OpenVPN box and create a situation where
the kernel/userspace transition cost does matter.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] linux openvpn development job

[Karl O. Pinc]

On 04/25/2009 12:50:26 PM, David Sommerseth wrote:


Karl O. Pinc wrote:
> On 04/24/2009 07:40:02 AM, Siim Põder wrote:

[snip]

> Please pardon me for thinking out loud here...

I'll follow in this path, thinking out loud ...

> The problem is that moving data between userspace and kernelspace
> is expensive.  (IIRC you can't just use the CPU to filter the bus
> between nics, you need to deliver data to/receive data
> from RAM because that's where the userland app works
> with it.)  OpenVPN runs in userspace so all the VPN data
> has to pass out of the kernel into userspace and back again.
> To attack the problem directly you need to move all functionality
> into the kernel, which raises a number of problems.



What if OpenVPN on selected platforms also provided it's own kernel
driver
which would do practically the same as the upstream tun.ko modules -
except it provides a direct API which OpenVPN can utilize, to avoid
the
kernel-userspace-kernel ping-pong.


That actually sounds approachable, from a thinking
out loud perspective.  I don't really know the
important details so can't judge.

In order to reduce latency and work the kernel
need only examine the IP headers.  The rest of the
datagrams can stay on the card.  Once the routing decision
is made the bus can deliver the datagram directly to the
appropriate nic's buffer.  This could be on the same
card if you've multiport nic cards or could be assisted
by dma or some such. This keeps down latency and offloads
the CPU.

As long as you're putting parts of OpenVPN in the kernel
it would be nice to leave as much of the tun module
alone as possible and have a separate OpenVPN kernel module.
You'd split out the part of OpenVPN that does the data channel
and put that in the kernel module, it would talk to the
kernel tun interface etc.  Everything else, all the
control channel auth stuff and the like, does not have
to be in the kernel because it's not high
performance/high volume.

As Siim pointed out you do need to move the whole datagram
into RAM if you're going to operate on it.  But if there's
encryption hardware support in the kernel additional
operations involving system RAM may not be required..
You may be able to go directly between the nic and the hardware
encryption engine and avoid RAM.  I've really no idea.

(I do know that one reason why I saw such bad
kernel/userspace performance in an embedded device
is due to sucky nic hardware.  It may require
good hardware to offload the CPU.)

I don't know how this would play with the OpenSSL API.
Ideally OpenSSL has provisions for being used inside
kernelspace so that it can directly access any hardware
engines.   Moving all the crypto calls from the OpenSSL
API to the kernel API sounds prohibitive although
you never know until you look.  Worst case
you'd not be able to use hardware acceleration if you
used a kernel module version of OpenVPN based on OpenSSL.

And of course, as you say, there's all sorts of opportunity
for insecurity when you introduce code into the kernel.
But the data channel code that goes in the kernel module
should already be hardened.

Regards the political considerations, if successful
such an approach could be attractive enough
that the OpenVPN developers couldn't ignore it.
Greatly improved performance could create enough
interest to support a fork, especially if the
necessary changes were minimal and could be ported
into future OpenVPN versions.  I don't want to
be seen in any way as agitating for such a fork,
and I certainly don't want to cast
any aspersions on the management of the OpenVPN
project.  My point here is only to explore
the prospects of the long-term maintenance of
an OpenVPN kernel module.

In the long-term the other aspect of such an approach
that needs addressing is the API between the kernel
module and the rest of OpenVPN.  Ideally the kernel
module would eventually be made part of the official
kernel.  I don't know the policy of the kernel
maintainers but I would think that an OpenVPN
kernel module would be more attractive if it
were usable by something besides the OpenVPN
application.  The big attraction of getting
a kernel module sanctioned by the kernel devs
is that there's no headaces with respect to
kernel version incompatibilities.  The in-kernel
API is not static so changes to any of the
nic drivers could affect system stability.

The above is an awful lot of thinking out loud,
especially because I don't really have any
involvement or familiarity with any internals.
Or any of the politics involved for that matter.
My intention here is to explore the entire
problem space; and when people become involved
politics ensues.  It's always a bad idea to
speak on political matters when you are not
on familiar ground, and that is what I've
done here.  I hope I have not stepped into
sensitive matters and apologize in advance
for any offense.

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: [Openvpn-devel] linux openvpn development job

[Karl O. Pinc]

On 04/24/2009 07:40:02 AM, Siim Põder wrote:

Hi

We are running a couple of openvpn servers with relatively high load
(Opterons 2xDC, e1000, recent kerneles) and it seems as if most of the
CPU time is not used on cryptography, but in softirq (send/recv for
udp
and read/write on tun?). This has lead us to suspect that most of the
time is spent pumping data between userspace and kernelspace.

Now, we are still investigating this, but I thought I'd ask around
too:.
Does anyone have a take on this, could a considerable (upwards of 10%)
increase in openvpn capacity be accomplished by optimizing udp/tun
interfaces of the kernel (a mechanism like ring buffers?) or are we on
a
wrong track?


Please pardon me for thinking out loud here...

The problem is that moving data between userspace and kernelspace
is expensive.  (IIRC you can't just use the CPU to filter the bus
between nics, you need to deliver data to/receive data
from RAM because that's where the userland app works
with it.)  OpenVPN runs in userspace so all the VPN data
has to pass out of the kernel into userspace and back again.
To attack the problem directly you need to move all functionality
into the kernel, which raises a number of problems.
Such an OpenVPN would not port between OS platforms
very well.  Someone would have to convince both
the kernel and OpenVPN developers to maintain the
code.  And so forth.

The question then becomes how much optimization can
be made between kernel and userspace beyond what's
already been done, again bearing in mind the both
the kernel and OpenVPN developers must be on-board
with the result.  Of course you could maintain the
resulting code, but you'd need to recognize
that, typically, at least 70% of software labor costs
are in maintenance.

Everybody wants faster userspace/kernelspace transfers
but everybody also wants a standard OS API.  The
Linux kernel developers provide feedback on ideas.
I don't know about the OpenVPN developers but
I've not seem much traffic here in the weeks
I've been subscribed.

I've seen embedded devices use upwards of 50% of
the CPU on the kernel/userspace transition.
Using hardware acceleration reduces performance
because it passes more data across the kernel/user
boundary.

IMO your money is better spent getting redundant hardware
and load balancing.  (E.g. you could run OpenVPN
on OpenBSD/carp and have a loadbalanced hot-failover
cluster.   Or use some other clustering solution.)
At least that's how I'd go without a good plan, and
buy-in from the OpenVPN developers.
After the initial investment the cluster solution will
scale linearly with dollars spent, and you get
increased reliability and fault-tolerance for free.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

[Openvpn-devel] What is the contribution process?

[Karl O. Pinc]

Hi,

I submitted 2 patches more than two weeks ago, and have not
heard anything back.  I just sent some more patches to
the list.

The first two are the patches that support a release of MS Windows
binaries in a non-installer format for those who wish
to have a custom installer.  The patches are here:

http://article.gmane.org/gmane.network.openvpn.devel/2578
http://article.gmane.org/gmane.network.openvpn.devel/2581

Should I expect to hear back from the developers regarding
whether they will/won't apply submitted patches because they
like/dislike certain particulars, what needs fixing, etc?

How does the process of contributing to the project work?

Thanks.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

[Openvpn-devel] Patch for more useful tls-verify script

[Karl O. Pinc]

The attached patch changes the verify-cn script sample
to be used with --tls-verify so that instead of having
to hardcode a cn in the configuration file the
allowed cns may be written into a separate file.

This makes the process of verifying cns a whole
lot more dynamic.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein
--- verify-cn.orig	2009-04-23 16:19:46.0 -0500
+++ verify-cn	2009-04-23 16:21:43.0 -0500
@@ -7,24 +7,28 @@
 #
 # For example in OpenVPN, you could use the directive:
 #
-#   tls-verify "./verify-cn Test-Client"
+#   tls-verify "./verify-cn /etc/openvpn/allowed_clients"
 #
 # This would cause the connection to be dropped unless
-# the client common name is "Test-Client"
+# the client common name is listed on a line in the
+# allowed_clients file.
 
-die "usage: verify-cn cn certificate_depth X509_NAME_oneline" if (@ARGV != 3);
+die "usage: verify-cn cnfile certificate_depth X509_NAME_oneline" if (@ARGV != 3);
 
 # Parse out arguments:
-#   cn-- The common name which the client is required to have,
-#taken from the argument to the tls-verify directive
-#in the OpenVPN config file.
-#   depth -- The current certificate chain depth.  In a typical
-#bi-level chain, the root certificate will be at level
-#1 and the client certificate will be at level 0.
-#This script will be called separately for each level.
-#   x509  -- the X509 subject string as extracted by OpenVPN from
-#the client's provided certificate.
-($cn, $depth, $x509) = @ARGV;
+#   cnfile -- The file containing the list of common names, one per
+# line, which the client is required to have,
+# taken from the argument to the tls-verify directive
+# in the OpenVPN config file.
+# The file can have blank lines and comment lines that begin
+# with the # character.
+#   depth  -- The current certificate chain depth.  In a typical
+# bi-level chain, the root certificate will be at level
+# 1 and the client certificate will be at level 0.
+# This script will be called separately for each level.
+#   x509   -- the X509 subject string as extracted by OpenVPN from
+# the client's provided certificate.
+($cnfile, $depth, $x509) = @ARGV;
 
 if ($depth == 0) {
 # If depth is zero, we know that this is the final
@@ -34,11 +38,19 @@
 # the X509 subject string.
 
 if ($x509 =~ /\/CN=([^\/]+)/) {
+$cn = $1;
 	# Accept the connection if the X509 common name
 	# string matches the passed cn argument.
-	if ($cn eq $1) {
-	exit 0;
+	open(FH, '<', $cnfile) or exit 1; # can't open, nobody authenticates!
+while (defined($line = )) {
+	if ($line !~ /^[[:space:]]*(#|$)/o) {
+		chop($line);
+		if ($line eq $cn) {
+		exit 0;
+		}
+	}
 	}
+	close(FH);
 }
 
 # Authentication failed -- Either we could not parse