Re: [Openvpn-devel] OpenVPN core development processes?
Hi,
On Wed, Jan 20, 2010 at 04:00:03PM +0200, Samuli Seppänen wrote:
> So something like this at first:
>
> http://users.utu.fi/sjsepp/openvpn/process_contributing_to_openvpn.png
>
> ... and later this:
>
> http://users.utu.fi/sjsepp/openvpn/process_contributing_to_openvpn_2.png
This makes sense to me. Especially since there is well-defined feedback
to the patch author what will happen with his work.
> The second process avoids unnecessary bottlenecks. Perhaps we could also
> have separate "experimental", "unstable" or "feature-testing" trees
> maintained by other people. The code from these would then flow into the
> main development tree. I believe these trees could we managed with Git
> even if the main development branch is in SVN.
The nice thing about git is that people can very easily do "experimental
branches" in their own repository, giving access to testers, without
having to have write access to SVN.
OTOH, the VCS used is just a tool to help the process, and not the
primary goal :-) - so I'm definitely not going to be religious about
git or svn or cvs or...
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] win32 openvpn-2.1.1 has bug with "nobind"?
Hi, On Wed, Jan 27, 2010 at 04:17:56PM +1300, Jason Haar wrote: > Confirmed. I have a server running on 1194 tcp and udp and Is this a single server listening on both ports, or is this two independent servers? (For a customer installation, I need a single server to listen on UDP/1194 and TCP/443, and as far as I understood so far, this was not possible) If this is indeed not possible yet, is anybody working on this? I might be tempted to tackle it, but would prefer to avoid duplicate work. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] win32 openvpn-2.1.1 has bug with "nobind"?
Hi, On Wed, Jan 27, 2010 at 09:32:05PM +1300, Jason Haar wrote: > On 01/27/2010 09:17 PM, Gert Doering wrote: > > Is this a single server listening on both ports, or is this two independent > > servers? > > server running openvpn on tcp:1195 and udp:1195 So it's two independent processes. > > (For a customer installation, I need a single server to listen on UDP/1194 > > and TCP/443, and as far as I understood so far, this was not possible) > > Yeah - can't be done. However, my problem is a client problem - you > sound like having a server problem. "nobind" only works in client mode Yes, sorry for hijacking your thread. Your remark about the server setup made me curious, so I jumped in. Can't help you with the client problem, though. > If you're using tun interfaces, you'll need to split your pool range > between the two instances. Or extend the code to make "listen on multiple ports" possible. >From a cursory glance, it won't be easy, as the code is full of special cases (blocking/non-blocking, udp/tcp, client/server side, all somewhat intermixed) and it will certainly require changes to data structures and to the MULTI code as well. Oh well. Let's see what time brings. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] New development process ready
Hi, On Thu, Feb 04, 2010 at 10:49:23AM +0100, David Sommerseth wrote: > I am willing to maintain a testing tree, Thanks. This is quite an important role, and I was refraining from volunteering because I *know* I don't have enough time. > but to make it maintainable and > flexible for my ideas around this I'd prefer to keep this in a git tree. > > [ git layout and process ] Makes sense to me. > But I must warn those who wants to contribute patches as well. I will > be critical and easily rejective if certain "rules" are not followed. > > - All patches should be useful and beneficial for several OpenVPN > users, not just for "special case" situations. > - All patches must contain an argumentation for *why* this patch > should be included and *how* it solves the issue in plain English. > - Everyone who has contributed to this patch should be mentioned, > with at least a valid e-mail address, preferably with full name in > addition. (I want to give credit to contributors!) > - All patches must be against the SVN development branch or git > master branch, at least until a feature branch is created. > - All initial patches must be sent as unified diff (diff -u) > - Patches must be sent to the openvpn-devel mailing list, at least > until a better patch tracker have been implemented. Would you be willing to consider pulling branches from other repositories? (I'm asking because the "IPv6 transport" stuff already lives in Berni's git repository, and this might make things easier) OTOH, running a "git diff" on our end is not that much work, though :-) > - Patches on the mailing list should preferably be start with [PATCH] > in the subject field. (This will not cause a direct rejection, but > I might miss a contributed patch when parsing the mailing list) > - Patches sent to me directly *will* be rejected. All patches must be > public and will be discussed in public. > - If a lot of merge conflicts turns up when applying the patch, I will > most likely reject the patch and ask for a new patch which applies > cleanly. Overall, I think these rules make lots of sense. I'd add another rule - All new code must be written following the OpenVPN coding conventions (code indenting, scratch memory handling with "gc", etc.) Long-term maintenance of code written with different indent styles and different ideas about memory management in different places is a nightmare. > If someone maintains their code in a git tree already, I am willing to > pull those git trees - as long as it will not cause any conflicts > against the master/SVN development branch I am maintaining. But! Pull > requests with an update of the changes must be sent to the mailing list. Ah :-) - Question from above answered. Cool. > Further, I would prefer if we could arrange with a ACK/NACK system of > patches. That means that patches goes through minimum a "code review" > by at least one other person on the openvpn-devel mailing list. And if > it looks good, it gives it either an ACK for acceptance or NACK for > disapproving it. Ideally, I would only implement those patches which > gets at least one ACK. The person ACKing would also be mentioned in the > commit log. This way, it's not only me who reviews patches and only > contributions which makes sense to implement are included - and we avoid > spoiling the code base with features which is only requested for very > special conditions. ACK! > It would be great if all patch contributors who have contributed patches > could contact me on IRC (freenode: ##openvpn-devel, nick: dazo), > especially if they are not sure or they know that their patch has not > been included yet in the SVN tree James keeps. Will do tonight :-) > Of course, I am only going to do this if the community *and* OpenVPN > company accept my offer. So unless somebody feel I'm not trustworthy or > not capable of doing this job, I will step aside and let others do this > job. No hard feelings :) But as I've not seen or heard about anyone > stepping up yet, so I take the chance of doing that now. Thanks for volunteering! gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] New development process ready
Hi, On Thu, Feb 04, 2010 at 04:58:51PM +0100, David Sommerseth wrote: > > I'd add another rule > > > > - All new code must be written following the OpenVPN coding conventions > > (code indenting, scratch memory handling with "gc", etc.) > > > > Long-term maintenance of code written with different indent styles and > > different ideas about memory management in different places is a > > nightmare. > > Very good point! I agree to this one. But this also hits another need, > a public developer documentation which describes this. Anyway, the > documentation need should be discussed in the meeting today as well. Yes, this has already been agreed-to on last week's IRC meeting and is on the "TODO list" - provide a style guide for OpenVPN code. Looking forward to see what I did wrong :) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Reworked the eurephia patch for inclusion to the openvpn-testing tree
Hi,
I can't claim to fully understand the crypto side of things, but from
the "coding standards" and "non-intrusiveness" point of view: ACK.
(All it does is sent an extra environment variable based on the
content of a well-defined memory buffer, using the APIs already existing
for that purpose, format_hex_ex() and setenv_str())
Someone with a better understanding of the crypto stuff should verify
that the ctx->current_cert->sha1_hash is always valid, and points to
a buffer of the necessary length.
gert
On Mon, Feb 15, 2010 at 11:28:13PM +0100, David Sommerseth wrote:
> From: David Sommerseth
>
> Addedd configure option (--disable-eurephia) to disable the code which the
> eurephia plug-in depends on.
>
> It was chosen to use --disable-eurephia, as this patch is not much intrusive.
> It
> just enables a SHA1 fingerprint environment variable for each certificate
> being
> used for the connection.
>
> Signed-off-by: David Sommerseth
> ---
> configure.ac |9 +
> options.c|6 ++
> ssl.c| 14 ++
> 3 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 116ff7c..e775665 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -99,6 +99,12 @@ AC_ARG_ENABLE(plugins,
> [PLUGINS="yes"]
> )
>
> +AC_ARG_ENABLE(eurephia,
> + [ --disable-eurephia Disable support for the eurephia plug-in],
> + [EUREPHIA="$enableval"],
> + [EUREPHIA="yes"]
> +)
> +
> AC_ARG_ENABLE(management,
> [ --disable-managementDisable management server support],
> [MANAGEMENT="$enableval"],
> @@ -632,6 +638,9 @@ if test "${WIN32}" != "yes"; then
> )],
> [AC_MSG_RESULT([libdl headers not found.])]
>)
> + if test "$EUREPHIA" = "yes"; then
> + AC_DEFINE(ENABLE_EUREPHIA, 1, [Enable support for the eurephia
> plug-in])
> + fi
> fi
> fi
>
> diff --git a/options.c b/options.c
> index c5ca8b6..aae954e 100644
> --- a/options.c
> +++ b/options.c
> @@ -7,6 +7,9 @@
> *
> * Copyright (C) 2002-2009 OpenVPN Technologies, Inc.
> *
> + * Additions for eurephia plugin done by:
> + * David Sommerseth Copyright (C) 2009
> + *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2
> * as published by the Free Software Foundation.
> @@ -73,6 +76,9 @@ const char title_string[] =
> #ifdef ENABLE_PKCS11
>" [PKCS11]"
> #endif
> +#ifdef ENABLE_EUREPHIA
> + " [eurephia]"
> +#endif
>" built on " __DATE__
> ;
>
> diff --git a/ssl.c b/ssl.c
> index 82e04a3..1936f64 100644
> --- a/ssl.c
> +++ b/ssl.c
> @@ -7,6 +7,10 @@
> *
> * Copyright (C) 2002-2009 OpenVPN Technologies, Inc.
> *
> + * Additions for eurephia plugin done by:
> + * David Sommerseth Copyright (C)
> 2008-2009
> + *
> + *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2
> * as published by the Free Software Foundation.
> @@ -780,6 +784,16 @@ verify_callback (int preverify_ok, X509_STORE_CTX * ctx)
>openvpn_snprintf (envname, sizeof(envname), "tls_id_%d", ctx->error_depth);
>setenv_str (opt->es, envname, subject);
>
> +#ifdef ENABLE_EUREPHIA
> + /* export X509 cert SHA1 fingerprint */
> + {
> +struct gc_arena gc = gc_new ();
> +openvpn_snprintf (envname, sizeof(envname), "tls_digest_%d",
> ctx->error_depth);
> +setenv_str (opt->es, envname,
> + format_hex_ex(ctx->current_cert->sha1_hash, SHA_DIGEST_LENGTH,
> 0, 1, ":", &gc));
> +gc_free(&gc);
> + }
> +#endif
> #if 0
>/* export common name string as environmental variable */
>openvpn_snprintf (envname, sizeof(envname), "tls_common_name_%d",
> ctx->error_depth);
> --
> 1.6.6
>
>
> ------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [ANNOUNCE] IPv6 payload patch
Hi,
On Tue, Feb 16, 2010 at 12:12:22AM +0100, David Sommerseth wrote:
> On 18/01/10 23:09, Bernhard Schmidt wrote:
[..]
> As a newly appointed maintainer for the openvpn-testing repository, I
> tried to merge in these changes into the testing repository. But I got
> an enormous amount of merge conflicts, which was not too much trivial to
> solve some places.
Just for the record - this got sorted out, the problem was not with the
IPv6 patch but with the way two different git repositories where built
from SVN.
Bernhard has rebuilt his git repository now, and David has integrated
the IPv6-payload patch into the "testing" OpenVPN git repository (thanks!).
> The openvpn-testing.git tree can be found here:
>
The IPv6-payload patch has been tested in a number of networks for the
last 6 weeks, and so far, it has done what was configured, and not broken
anything else.
Nevertheless I do not consider it ready for inclusion into the mainstream
tree yet - it lacks full documentation, testing of other scenarios than
"server-to-client tun", and I would very much like to get more feedback and
review on the way it is currently implemented, and whether something
should be done in a fundamentally different way.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [IPv6 support] - usage of gethostbyname() in getaddr()
Hi, On Wed, Feb 17, 2010 at 02:47:28PM +0100, David Sommerseth wrote: > When reviewing the patch "FQDN for routes should expand to all IPs" > today, I spotted that there is a function called getaddr() (renamed to > getaddr_all() in the mentioned patch). This function again makes use of > the old gethostbyname() function. This is not compatible with IPv6 > addresses. This is actually "existing code", and not something changed by the patch (just to point that out to readers that have not reviewed the patch). > I would strongly recommend a move to getaddrinfo() instead. This is > based on an article [1] written by Ulrich Drepper, who is a glibc > maintainer. Any thoughts about that? It might even be more functions > needing to be ported as well. The mentioned article lists most > important functions which should be ported to newer APIs. > > Any comments on this issue would be appreciated. Another issue is of > course how this will influence other platforms than Linux. Well, let me answer the second thing first (because I've spent a while thinking about this and whether I want to make the IPv6 payload stuff #ifdef'ed from the start). On the Unix side of things, I'm fairly sure that any platform recent enough to have tun/tap support (which isn't all of them, just *BSD, Solaris, Linux and MacOS) also has getaddrinfo() and IPv6. I don't know a thing about Windows programming, though. OpenSSH tackles this by providing their own getaddrinfo() function (from OpenBSD) if the system has no such function, or if it is broken, and "configure" seems to do a good job in deciding what to do. Now, on the question of whether we want / should use it. Right now, the "upstream" code only uses gethostbyname() because it wouldn't know what to do with an IPv6 record anyway, if any such record were to be returned - the code is used for connection handling (IPv4 only) and for setting routes to FQDN (again, IPv4 only). In the long term, this whole area of the code will see some changes :-) - when merging jjo's tree, we should already see use of getaddrinfo() for connection handling, and if people see the need for it, I might need to implement setting of IPv6 routes to FQDN targets. So... if you'd ask me what I would to today, the answer would be "leave the code as it is, merge jjo's code, and then revisit what he already had to change for IPv6 connection handling". If gethostbyname() is still there, come back and make this lookup function v4- and v6-capable, and implement FQDN routes for IPv6 :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs
Hi,
On Thu, Feb 18, 2010 at 12:54:08PM +0100, David Sommerseth wrote:
> The average user might have hits between 1 and 5 IP addresses
> (guestimate) on such a hostname lookups. There are a few things I am
> concerned about in this regards. Even though on my platform in_addr_t
> only needs 4 bytes, other platforms might use more. If that platform is
in_addr_t is an IPv4 address, so I would be very surprised to see it require
more than 4 bytes on any reasonable system.
[..]
> Remember that the memory which is allocated "static" in functions like
> you have done, are in the reality allocated dynamically when the
> function is called. The advantage is this approach, is that it is
> easier for developers to write the code. The developer don't need to
> care about explicit malloc() or calloc() calls, neither to free the
> memory afterwards. The compiler does this job for you. (Global
> variables on the other hand, are different in this regards, but that's
> another chapter.)
Just to nitpick on that: those variables are not malloc()'ed, they are
put on the stack. Different area of the memory management -- but still
valuable on embedded systems, of course.
Since the openvpn server process is not multithreaded, there is no risk
of it happening "10 times in parallel", though. So we lose 400 bytes
of stack space while getaddr() is called.
[..]
> 1) Make use of dynamic memory allocation
> You return number of IPs retrieved, so you know how much data to free
> later on. You might also want to have a configuration parameter which
> can limit the amount IPs allowed to be processed. This also gives users
> with restricted memory usage better control.
I see this specific case as "somewhat borderline" - adding dynamic
memory handling will save 400 bytes of stack space (good) but will bring
in extra code for sizing, allocating, and free()ing the memory, which
might well end up being in the same order of bytes of code space - and
that's memory "lost forever". And the risk of programmer error is higher...
> 2) Reduce MAX_IPS_PER_HOSTNAME and make this a default value. Then make
> this number changeable via a configuration option (in options.c). For
> me a reasonable default number would be 5 or 10 in this situation.
Getting configuration options propagated down all the way into a generic
function like getaddr() is either painful (lots of callers that might
themselves not have a pointer to the config struct around yet) or messy
(global variables).
Reading through this, my suggestion would be "go for a reasonable but
lower value", something like "20". Still arbitrary, but brings down the
(transient!) memory used to 80 bytes, which is hard to beat with any sort
of dynamic allocation scheme.
> * 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.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Make sample-scripts/verify-cn dynamic
Hi, On Thu, Feb 18, 2010 at 11:58:27AM -0600, Karl O. Pinc wrote: > Re: [PATCH] Change verify-cn so cn is no longer hardcoded in openvpn's config > file ACK from my end. The code looks sane and I can see the usefulness. (Backwards compatibility would be very easy to add - "if the argument does not start with a "/", treat as CN - but as you said, this is just a sample script anyway). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Do not randomize resolving of IP addresses in getaddr()
Hi,
ACK for the idea, but this...
On Thu, Feb 18, 2010 at 09:23:48PM +0100, David Sommerseth wrote:
> - /* choose address randomly, for basic load-balancing capability */
> - ia.s_addr = *(in_addr_t *) (h->h_addr_list[get_random () % n]);
> + ia.s_addr = *(in_addr_t *) (h->h_addr_list[0]);
> }
... is sort of redundant, because the code further up already sets
ia.s_addr = *(in_addr_t *) (h->h_addr_list[0]);
- in about line 202 in my copy of socket.c:
snip -
ia.s_addr = *(in_addr_t *) (h->h_addr_list[0]);
if (ia.s_addr)
{
if (h->h_addr_list[1]) /* more than one address returned */
snip -
so the if() could be reduced even further, to just print the message.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [IPv6] Merge conflicts in mroute.c (was: Re: openvpn-testing tree available)
Hi,
On Fri, Feb 19, 2010 at 12:10:29PM +0100, David Sommerseth wrote:
> >> I still need to do some touches for allmerged, as
> >> we conflict w/ Gert's IPv6 patch on a mroute.c chunk
> >> IIRC.
>
> Even though I know you both have told me that there would be a merge
> conflict in mroute.c, I decided to put it on the mailing list -
> hopefully to get an open discussion about it!
Good :-)
> I've attached the merge conflict. It would be great if you could sort
> this out soon. Then I'll get both of your trees into the allmerged
> branch ASAP. Right now only Gert's code is in the allmerged branch.
For the allmerged, you could use either one, or none at all(!) :-)
*I* think you should use mine, of course. Reason explained below.
> What I do see might be a challenge (without knowing the code in
> details), is that JJO's code is using #ifdef, while Gert's code is not.
> With a conflict in mroute_addr_print_ex(), which includes an #ifdef I
> see a potential disaster here.
The code basically does the same thing "add printing of the IPv6
information for a mroute structure containing IPv6 information".
For OpenVPN to *work*, you need neither, it's just helpful diagnostic
output :-) - if the code is unpatched, it will just do
buf_printf (&out, "IPV6");
for IPv6 mroutes, but not error-abort or fail. So no danger here.
Now, for the different patches.
My patch "just prints the IPv6 address", using a helper function that
I added elsewhere (print_in6_addr()). This function is not available
in the official tree, so JJO cannot use it for his branch.
JJO's patch does more than that, he does DNS lookups to print the
DNS name for the IPv6 address in question. Now we enter religious
territory - *I* think that this is not a good thing. The existing
code doesn't do reverse DNS lookups for IPv4 mroute printing, and so
the IPv6 code should behave similar to the IPv4 code, and not do DNS
either (also, depending on DNS lookup in this place might lead to
weird delays in unexpected situations). But this is partly religious,
partly "follow the coding style of the existing code" stuff.
JJO's patch also adds the port number for MR_WITH_PORT mroutes - which
is something that never happens for my usage of IPv6 mroutes for
IPv6 payload - but that could be easily added to my code.
> Personally, I would like to evaluate Gert's patches to see if they could
> be #ifdef'ed. Then both IPv6 branches can both use USE_PF_INET6 to
> enable or disable the IPv6 support. I have not studied these patches,
> so I don't know how doable that is. And this is my personal opinion, I
> don't mean to instruct anyone into a direction. I will let you guys
> find the proper direction.
Most changes of my patch could be #ifdef'ed easily - places that just add
extra lines of code, extra fields to a structure, and such. That's the easy
stuff.
Other parts are much harder, changes like this one:
/* possibly add routes */
if (!c->options.route_delay_defined)
- do_route (&c->options, c->c1.route_list, c->c1.tuntap, c->plugins, c->c2
.es);
+ do_route (&c->options, c->c1.route_list, c->c1.route_ipv6_list,
+ c->c1.tuntap, c->plugins, c->c2.es);
... where I had to add extra arguments to a function call. #ifdef'ing
that is going to produce really ugly and much harder-to-maintain code
(because you have to have an #else, with the old call syntax, and
future changes of this function call always have to adjust *both*
changes).
I've just re-checked JJO's patch - the #ifdef's in there don't cover
all the changes either, just the IPv6-specific stuff. The necessary
changes to the existing IPv4 infrastructure (data structures etc) are
not #ifdef'ed - so the #ifdef's here don't serve to deactivate the
whole patch, but only to disable the actual IPv6 transport functionality.
Personally, I'm not a big fan of #ifdef'ing changes that affect so many
different places of the code (JJO's patch has 109 chunks, my patch
has 119 chunks) because it will make the code much harder to read, and
also harder to test ("how many different combinations of compile-time
options need to be enabled to cover all possible code paths?").
But if that is what it takes to get the code integrated in the main
source, that's what I'll do.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [IPv6] Merge conflicts in mroute.c (was: Re: openvpn-testing tree available)
Hi, On Fri, Feb 19, 2010 at 03:21:34PM +0100, JuanJo Ciarlante wrote: > > JJO's patch does more than that, he does DNS lookups to print the > > DNS name for the IPv6 address in question. > > Wrong. > From getaddrinfo(3): >""" > If hints.ai_flags contains the AI_NUMERICHOST flag then the node > parameter must be a numerical network address. > The AI_NUMERICHOST flag suppresses any potentially lengthy > network host address lookups. >""" Ah! Learned something new today. So what's the specific advantage of using getnameinfo() instead of inet_ntop() instead? (I've only ever used getnameinfo() if I really wanted to do DNS lookups). > > Now we enter religious > > territory - *I* think that this is not a good thing. > > I can't more eagerly _agree_ on tossing out any reverse > DNS lookups at this level. OK, good. Glad that this was just a misreading of the code. > > The existing > > code doesn't do reverse DNS lookups for IPv4 mroute printing, and so > > the IPv6 code should behave similar to the IPv4 code, and not do DNS > > either (also, depending on DNS lookup in this place might lead to > > weird delays in unexpected situations). But this is partly religious, > > partly "follow the coding style of the existing code" stuff. > > IMO we should void using inet_ntop() and friends, personally > I don't like locking around their lack of multi-threading. Mmmh, ok. I wasn't aware that inet_ntop() is not thread-safe. (Looking at the FreeBSD implementation, at least that one *is* thread-safe - no static buffers, etc.). If it is not thread-safe, it won't break anything in my code, though (lucky me :-) ) - my use of it in print_in6_addr() is mutex-locked anyway, due to the use of a static buffer there. Is getnameinfo() *guaranteed* to be thread-safe? Do you have a reference that documents that inet_ntop() and inet_pton() are unsave to be used in a threaded context? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [IPv6] Merge conflicts in mroute.c (was: Re: openvpn-testing tree available)
Hi, On Fri, Feb 19, 2010 at 03:34:41PM +0100, David Sommerseth wrote: > So I lean towards JJO here, as far as possible, avoid using functions > which are not thread safe. I'm not yet convinced that inet_ntop() is actuall not thread-save - but independent of that, it's not a tie-breaker here :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [IPv6] Merge conflicts in mroute.c (was: Re: openvpn-testing tree available)
Hi, On Fri, Feb 19, 2010 at 03:29:48PM +0100, David Sommerseth wrote: > I'm fine with whichever path you choose. But just bear in mind, some > systems might not have IPv6 support - which breaks portability ... On the unixish side, there is no system which has tun/tap today but does not have IPv6. On Windows, this might indeed be a killer argument to do some #idef'ing - what's the oldest version of Windows officially supported by OpenVPN? (XP and up has IPv6, everything before that does not) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] verb 5 logging wrongly reports received bytes
Hi, On Fri, Feb 19, 2010 at 05:37:48PM +0100, David Sommerseth wrote: > ACK > > Patch looks sensible, and applies cleanly to the master branch. ACK. I can see the reason for doing so (as I'll have a device "soon" that will return 0 from tun device reads under certain circumstances) and it doesn't break current usage. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs
Hi, On Fri, Feb 19, 2010 at 05:18:29PM +0100, David Sommerseth wrote: > I initially meant a more dynamic approach, changing it via the config > file at runtime - by modifying a global C variable. But I agree, doing > it via the ./configure script should really be sufficient. ACK. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [IPv6] Merge conflicts in mroute.c
Hi, On Fri, Feb 19, 2010 at 12:50:10PM -0500, Stefan Monnier wrote: > >> I'm fine with whichever path you choose. But just bear in mind, some > >> systems might not have IPv6 support - which breaks portability ... > > On the unixish side, there is no system which has tun/tap today but > > does not have IPv6. > > What about embedded systems using uclibc compiled "without ipv6 support"? I have not yet encountered any such system. That doesn't mean they don't exist, it's just "I have not yet seen them". My OpenWRT does IPv6, and that's the smallest system I have. > Or is that some different kind of "support" that wouldn't affect your code? I have to investigate. I'd assume that the necessary header files (that provide necessary compile- time things like "struct in6_addr") are still complete, and that only the run-time which is installed on the device itself will be reduced. If the net effect of the change is "function calls like inet_ntop() are there but refuse to handle AF_INET6 things (with an error message)", it won't break OpenVPN - the IPv6 stuff will not work, but it will not break the IPv4 stuff. If the net effect is "dynamic linking fails because inet_ntop() or getaddrinfo() are not even available in the library", this would be very bad - but it would be surprising, since developers have been told to use the address-family independent functions (like getaddrinfo()) for 10 years now, so this would break more applications. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Summary of the IRC meeting (18th Feb 2010)
Hi, On Fri, Feb 19, 2010 at 02:48:44PM +0200, Samuli Seppänen wrote: > Here's the summary of last week's meeting. Thanks, > Btw. what do you think about including the full IRC chatlog in these > emails? It would make it much easier to see exactly what was discussed. > After all, the summary is only my personal interpretation of the discussion. No objections. It's an open discussion after all. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [IPv6] Merge conflicts in mroute.c
Hi,
On Fri, Feb 19, 2010 at 08:33:04PM +0100, Gert Doering wrote:
> > [uclibc without UCLIBC_HAS_IPV6]
>
> I have to investigate.
And so I did. The impact of UCLIBC_HAS_IPV6=0 is fairly low:
- getaddrinfo() will not resolve IPv6 addresses (but *will* be available)
- the external globals in6addr_any and in6addr_loopback will not
be compiled in (in6_addr.c).
** I expect this to cause linking problems for my code **
- inet_ntop6() and inet_pton6() will not be compiled-in - both are only
called indirectly, from inet_ntop() and inet_pton(), respectively, for
af AF_INET6. So trying to convert IPv6 addresses will fail at run-time.
[side note: that's actually the same code as in the FreeBSD libc,
and as such, fully threadsafe :-) )
- __opensock() refuses AF_INET6 sockets at run-time
- the resolv.c functions (gethostbyname2, gethostbyaddr, __dns_lookup,
__read_etc_hosts_r, gethostent, ...) will not resolve / handle IPv6
addresses
- the relevant *definitions* (struct in6_addr etc) are all there, all
the time, and not depending on UCLIBC_HAS_IPV6.
I don't have a system available for testing, but I would expect that
OpenVPN with my patches compiled/linked against an IPv4-only uClibc
would fail due to unavailability of "in6addr_any", which can be fairly
easily worked-around [reports welcome!].
The other stuff should not cause any adverse run-time effects - if IPv6
isn't compiled in the library, OpenVPN will just not accept
"--ifconfig-ipv6" and similar commands (because parsing the IPv6
addresses fails, and thus the addresses are refused as "invalid"), but
everything else will just work as-is.
As said: I would welcome contact to someone who is using uClibc+OpenVPN
and could help me test this and adapt the code if needed.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [IPv6] Merge conflicts in mroute.c
Hi,
On Fri, Feb 19, 2010 at 04:53:31PM -0600, Karl O. Pinc wrote:
> > As said: I would welcome contact to someone who is using
> > uClibc+OpenVPN
> > and could help me test this and adapt the code if needed.
>
> To run the risk of harping on a theme
>
> If the problem is that someone is './configure --no-ipv6'-ing
> ipv6 away then maybe openvpn needs to have a similar ./configure
> option? Or could ./configure just test against UCLIBC_HAS_IPV6?
This is where this discussion started: do we really need to #ifdef
the IPv6 related code in OpenVPN, or can we assume that any recent OS
that has tun/tap will provide the necessary functions anyway.
Adding lots of #ifdefs doesn't improve code readability and feature
testing, and makes future maintenance harder (because it's not always
obvious if something you change might break a different combination of
optional compile-time features that what you use).
For uClibc, the answer could be "it should be sufficient to just define
'in6_addr_any' locally in OpenVPN code, if uClibc is detected" - that's
just 16 bytes of static data.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH v2] Do not randomize resolving of IP addresses in getaddr()
Hi, On Fri, Feb 19, 2010 at 11:57:30PM +0100, David Sommerseth wrote: > (I'm withdrawing the first version, and suggesting this patch to be used > instead, > as this one follows the new feature deprecation process.) ACK! gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] make ipv6_payload compile under windowze ( feat_ipv6_payload branch )
Hi,
On Sun, Feb 21, 2010 at 08:00:27PM +0100, JuanJo Ciarlante? wrote:
> This patch makes ipv6_payload successfully cross *compile*
> (and just that :) under my mingw32msvc setup on Linux.
Oh, cool! Thanks a lot for that.
I'll try to figure out how to setup a cross-compile environment
during next week, and then I'll try to figure out how to get the
IPv6 ifconfig & IPv6 route stuff done (if nothing else helps, run
"netsh" commands to do the work...).
> Because same syshead.h changes are already included in
> feat_ipv6_transport, it may merge-conflict applying it over
> allmerged once the latter includes ipv6_transport.
Shouldn't git sort this out, if it's exactly the same change?
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] make ipv6_payload compile under windowze ( feat_ipv6_payload branch )
Hi, On Sun, Feb 21, 2010 at 09:03:11PM +0100, Peter Stuge wrote: > Gert Doering wrote: > > I'll try to figure out how to setup a cross-compile environment > > during next week, > > Some Linux distributions have premade mingw packages. > > In Gentoo building a toolchain for mingw is as simple as: > > emerge crossdev && crossdev -t i686-mingw32 > > On other distributions you might benefit from Dan Kegel's crosstool: > > http://kegel.com/crosstool/ > > Then run ./configure --host=i686-mingw32 && make in the OpenVPN > source tree to build using the cross-toolchain. Thanks for that. I was googling in parallel, and that's exactly what is going on in the background here right now (crossdev building the mingw environment) :-) I saw a note here on the list a few weeks ago pointing to the opensc "build" tool, and I'll try that, as soon as the cross-tools are done. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Gentoo Git-Live-Ebuild
Hi, On Wed, Feb 24, 2010 at 02:24:39PM +0100, Marcel Pennewiß wrote: > following the discussions and new patches i adapted the current Gentoo Ebuild > to use the allmerged-testing-tree (openvpn-.ebuild). This is really cool, thanks. > In march i'll try to setup a full ipv6-setup using Gert's payload-patch. This > setup could be tested by our members during daily use. If you need any help with that, you know where to find me :-) > Maybe some livebuilds for ubuntu/debian will be available then? Chances are pretty good, from the rumors I've heard on IRC... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] FRP: Present a warning on deprecated features during start-up
Hi, On Mon, Feb 22, 2010 at 10:41:49PM +0100, David Sommerseth wrote: > From: David Sommerseth > > Added a new function, warn_deprecated_features(), which is located in > deprecated.[ch]. All deprecated features should present a warning here. > This function will be called during start-up and will show all warnings > after the OpenVPN title string. > > Included a deprecated feature warning for the resolv-random feature. > > Signed-off-by: David Sommerseth ACK! gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Add CID to the management status overview
Hi,
On Sun, Feb 28, 2010 at 01:50:35PM +0100, David Sommerseth wrote:
> There are commands in the management interface which require the cid. The
> only way at the moment to get the cid of connected clients is to have
> always a management connection established. The patch adds the CID to the
> status output.
What is "cid"? Client-ID?
I can't ACK this, as I don't understand the implications. The code itself
looks harmless, but without knowing who might read the output and whether
an additional field will be silently ignored or whether consumer applications
may fail, I really can't say.
Is there documentation available for this?
Something I do not like about this patch:
> @@ -777,7 +777,7 @@ multi_print_status (struct multi_context *m, struct
> status_output *so, const int
>
> status_printf (so, "END");
> }
> - else if (version == 2 || version == 3)
> + else if (version == 2 || version == 3 )
> {
> const char sep = (version == 3) ? '\t' : ',';
>
In the grand scheme of things, small whitespace changes might later on
lead to a merge conflict with another patch in this line (like "introduce
version 4" or so), and so I'd avoid changes that are purely cosmetic in
a "feature" patch.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
[Openvpn-devel] special-case code for OpenBSD - advice needed
Hi,
while working on "make IPv6 payload work on Win32", I found something
quite peculiar for OpenBSD in the OpenVPN code.
In "init.c", do_open_tun(), calls two other functions from tun.c for
tunnel setup:
open_tun() --> find free /dev/tun device, open() it, thereby
activating a "tun" network interface, store the device
name in "struct tuntap", etc.
and
do_ifconfig() --> run "ifconfig tun 1.2.3.4" system commands
(basically consists of a ton of
#if defined(TARGET_nnn) ... #else blocks, containing
the system specific variations of "ifconfig" commands.
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()
This is controlled by the inline_function "ifconfig_order()" in tun.h,
which returns IFCONFIG_BEFORE_TUN_OPEN or IFCONFIG_AFTER_TUN_OPEN:
-- quote --
/*
* Should ifconfig be called before or after
* tun dev open?
*/
#define IFCONFIG_BEFORE_TUN_OPEN 0
#define IFCONFIG_AFTER_TUN_OPEN 1
#define IFCONFIG_DEFAULT IFCONFIG_AFTER_TUN_OPEN
static inline int
ifconfig_order(void)
{
#if defined(TARGET_LINUX)
return IFCONFIG_AFTER_TUN_OPEN;
#elif defined(TARGET_SOLARIS)
return IFCONFIG_AFTER_TUN_OPEN;
#elif defined(TARGET_OPENBSD)
return IFCONFIG_BEFORE_TUN_OPEN;
#elif defined(TARGET_DARWIN)
return IFCONFIG_AFTER_TUN_OPEN;
#elif defined(TARGET_NETBSD)
return IFCONFIG_AFTER_TUN_OPEN;
#elif defined(WIN32)
return IFCONFIG_BEFORE_TUN_OPEN;
#else
return IFCONFIG_DEFAULT;
#endif
}
-- quote --
I am ready to accept that Windows is weird, and needs special-casing of
stuff, but the OpenBSD case baffles me - it's a BSD after all, and all
other BSDs do it the other way round.
Now, reading through the code, OpenBSD, NetBSD and Darwin (MacOS X)
are actually very similar - that is, tun devices are persistent, and you
need to do "ifconfig tun destroy" before doing the target ifconfig,
otherwise you can have "leftover" configuration garbage there. Still,
NetBSD and Darwin do "IFCONFIG_AFTER_TUN_OPEN".
So...
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).
Question #2: (more a style question) - why is this function so convoluted,
if all the operating systems default to the default anyway - so why not
change it to:
static inline int
ifconfig_order(void)
{
#if defined(TARGET_OPENBSD)
return IFCONFIG_BEFORE_TUN_OPEN;
#elif defined(WIN32)
return IFCONFIG_BEFORE_TUN_OPEN;
#else
return IFCONFIG_AFTER_TUN_OPEN;
#endif
}
I'm purposely not sending a patch right now, because I don't understand
the reason for the code being what it is.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Allow 'lport 0' setup for random port binding
Hi, On Sun, Feb 28, 2010 at 02:44:14PM +0100, David Sommerseth wrote: > I am running a multihomed host where 'local ' must be specified > for proper operation. Unfortunately, this implies 'lport 1194' or > another static port. > > This causes problems with stateful firewalls which register the host/port > pairs in the internal connection tracking table. On ungraceful reconnects, > the new TCP connection will have same the host/port pairs but unexpected > sequence numbers. The new connection will be assumed as invalid hence and > be dropped. > > It would be nice when local port can be configured to be bound to a > random port number. After reading code, I have not found a reference anywhere that documents that bind() can be used with port=0 to tell the system "bind to the IP address, but still use a random port". It seems to work though, and the code elsewhere does not seem to make any assumptions about "port != 0" (it is effectively just passed to bind(), and if bind() doesn't like it, an error exit occurs). Since it fixes a real-world problem, there is obvious need for it. -> ACK. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
[Openvpn-devel] FreeBSD funny in the code
Hi,
tun.c contains this code, in the
#elif defined(TARGET_FREEBSD)||defined(TARGET_DRAGONFLY)
part of do_ifconfig() (about line 983 in the IPv6 payload branch):
- snip
else {
if (tt->topology == TOP_SUBNET)
argv_printf (&argv,
"%s %s %s netmask %s mtu %d up",
IFCONFIG_PATH,
actual,
ifconfig_local,
ifconfig_remote_netmask,
tun_mtu
);
else
argv_printf (&argv,
"%s %s %s netmask %s mtu %d up",
IFCONFIG_PATH,
actual,
ifconfig_local,
ifconfig_remote_netmask,
tun_mtu
);
}
- snip
Is it just me needing new glasses, or is this twice the very same code,
with a little bit of different indentation?
If other people see this too, I'll send in a patch that drops the
duplicate bits. The tun.c code is still hard enough to read...
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
[Openvpn-devel] Macos X / Darwin funny in the code
Hi, today is the day... :-) tun.c, do_ifconfig() contains this beauty... #elif defined(TARGET_DARWIN) /* * Darwin (i.e. Mac OS X) seems to exhibit similar behaviour to OpenBSD... */ argv_printf (&argv, "%s %s delete", IFCONFIG_PATH, actual); argv_msg (M_INFO, &argv); openvpn_execve_check (&argv, es, 0, NULL); msg (M_INFO, "NOTE: Tried to delete pre-existing tun/tap instance -- No Pr oblem if failure"); ... which doesn't work on 10.5 (at least), because there is no "ifconfig ... delete" command - to get rid of an interface, you need to call "ifconfig ... destroy". So all this would do is configure the tun interface to the IP address of a host named "delete", if such a host exists... Sun Feb 28 17:22:03 2010 us=91225 /sbin/ifconfig tun0 delete ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address At least on 10.5, this code is not needed at all, because the tun0 interface is auto-destroyed after closing it, so it's just superfluous and broken code. What I cannot test is: is it required on 10.4, 10.3, ...? If yes, which versions of MacOS X need it, and should we add a "configure" test for it? (I'm afraid this needs going back in the svn logs who did the MacOS X port and check with him...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Add CID to the management status overview
Hi,
On Sun, Feb 28, 2010 at 04:31:53PM +0100, David Sommerseth wrote:
> > In the grand scheme of things, small whitespace changes might later on
> > lead to a merge conflict with another patch in this line (like "introduce
> > version 4" or so), and so I'd avoid changes that are purely cosmetic in
> > a "feature" patch.
>
> Dang! This one slipped through. I spotted it, fixed it, but for some
> reason I recreated the patch file and forgot I had fixed it. Gert, I
> completely agree with you!
:)
> I'll promise to fix this one when merging it into the git tree, is that
> good enough for you, Gert?
Yes, I'm fine with that.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
[Openvpn-devel] Win XP problem with framedyn.dll and PATH settings
Hi,
I've been working on IPv6-Payload support on Windows over the last few
days, and made some progress. Cross-compile succeeds, the resulting binary
works fine for IPv6 and does some of the movements needed for IPv6.
I have decided to use "netsh" commands to setup IPv6, as this seems to be
"the canonical way" to do things.
There is one problem here: for every "netsh interface ipv6 add route"
command that I call (via openvpn_execve_check()), I get an error popup
about "framedyn.dll" not being found.
If I run the very same command from "cmd.exe", it succeeds.
Googling suggests that this might be a %PATH% setting issue:
http://www.dll-error-fixes.com/guide-fix-missing-framedyndll-error/
but checking the path on my system, everything seems to be fine (and the
DLL is there, in c:\windows\system32\Wbem\framedyn.dll, just fine).
If I change the config file and add "script-security 1 system" (instead of
the default, "... execve"), the commands work and yield no errors.
So. Looking at the code, it seems that %PATH% is never set for the execve
method - there's a set_win_sys_path() routine, but that sets %SystemRoot%,
not %PATH%.
I'm not exactly sure what the best way to fix this, which is why I bring
this up here, for discussion and feedback.
My current workaround is to have win32/env_block always add a static
PATH if no PATH is found in "es" - this is ugly, and not the right way
to go forward, but it helps me to work on the IPv6 bits for the time
being. (See below). An alternative way would be to copy %PATH% to "es"
upn startup (on Windows), or add another config variable "win-path" or
whatever.
Feedback requested!
gert
diff --git a/win32.c b/win32.c
index eb94eb8..7c57f1e 100644
--- a/win32.c
+++ b/win32.c
@@ -874,16 +874,21 @@ win_safe_filename (const char *fn)
static char *
env_block (const struct env_set *es)
{
+ char * force_path =
"PATH=C:\\Windows\\System32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem";
+
if (es)
{
struct env_item *e;
char *ret;
char *p;
size_t nchars = 1;
+ bool path_seen = false;
for (e = es->list; e != NULL; e = e->next)
nchars += strlen (e->string) + 1;
+ nchars += strlen(force_path)+1;
+
ret = (char *) malloc (nchars);
check_malloc_return (ret);
@@ -895,7 +900,18 @@ env_block (const struct env_set *es)
strcpy (p, e->string);
p += strlen (e->string) + 1;
}
+ if ( strncmp(e->string, "PATH=", 5 ) == 0 )
+ path_seen = true;
+ }
+
+ /* make sure PATH is set */
+ if ( !path_seen )
+ {
+ msg( M_INFO, "env_block: add %s", force_path );
+ strcpy( p, force_path );
+ p += strlen(force_path) + 1;
}
+
*p = '\0';
return ret;
}
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] FreeBSD funny in the code
Hi,
On Sun, Feb 28, 2010 at 04:37:45PM +0100, David Sommerseth wrote:
> On 28/02/10 16:10, Eric F Crist wrote:
> > ACK,
> >
> > It's not you, that's duplicate code.
>
> ACK. I this is indeed duplicated.
Thanks. I have committed this to my branch (because I'm too tired right
now to get branching right) as dd66b12647852e3f1267be70b0fb3b11deedf377
David, could you please pull my branch from Berni, and move that patch
to wherever bugfixes/code cleanups go? It should merge easily into
all branches.
(As a side note: there is new IPv6 related code in my branch, of course,
so please pull that to feat_ipv6_payload as well :-) - mostly code cleanups,
and Win32 preparations)
thanks,
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] make ipv6_payload compile under windowze ( feat_ipv6_payload branch )
Hi, to follow up on this... On Sun, Feb 21, 2010 at 09:14:16PM +0100, Gert Doering wrote: > On Sun, Feb 21, 2010 at 09:03:11PM +0100, Peter Stuge wrote: > > Gert Doering wrote: > > > I'll try to figure out how to setup a cross-compile environment > > > during next week, > > > > Some Linux distributions have premade mingw packages. > > > > In Gentoo building a toolchain for mingw is as simple as: > > > > emerge crossdev && crossdev -t i686-mingw32 [..] > > Thanks for that. I was googling in parallel, and that's exactly > what is going on in the background here right now (crossdev building > the mingw environment) :-) > > I saw a note here on the list a few weeks ago pointing to the opensc > "build" tool, and I'll try that, as soon as the cross-tools are done. I have been able to successfully build OpenVPN.exe from Linux, using the crossdev-provided "i586-mingw32msvc" environment. The resulting binary is compatible with the openvpn-gui from the "official" installer, as long as I install my cross-compiled .DLLs as well as openvpn.exe - the "shipped" DLLs don't work, but that's not really a problem right now. My largest problem right now is that the tun/tap driver does not support IPv6 if in "tun" mode - the code is quite explicit about it... tap-win32/tapdrvr.c, line 1568: //=== // In Point-To-Point mode, check to see whether // packet is ARP or IPv4 (if neither, then drop). //=== (there's good reasons for what it does) Now... is there someone who has worked on this before, and can help me a bit with it? Initial questions: - can it be cross-compiled? If yes, how? If no, what needs to be done on Windows to compile it? (I have *no* experience with Windows, but I can follow instructions and read documentation). - what needs to be done to install the driver / replace the existing driver? - how does one debug Windows drivers? Is there a printf() as in Linux that goes to console / syslog? gert PS: ifconfig + route work fine, and receiving packets also works (verified with wireshark). Just sending win->tun->openvpn doesn't -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] special-case code for OpenBSD - advice needed
Hi,
On Sun, Feb 28, 2010 at 10:13:10PM -0600, Karl O. Pinc wrote:
> 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.
You need ifconfig to set an IP address :-) - which might be considered
"odd frobbing", but people seem to value it somehow ;-)
In addition to that, on OpenBSD and NetBSD, Tunnel interfaces stay around
even after /dev/tun is closed, so if you want to be sure that no old
configuration lingers around and messes with your tunnel, the "safe"
approach is to do "ifconfig tun0 destroy ; ifconfig tun0 create" before
IP/IPv6 configuration.
*That* part is easily understood - the interesting question is why OpenVPN
does do_ifconfig/open_tun for OpenBSD and open_tun/do_ifconfig for NetBSD.
(As a side note: are you running an OpenBSD system and could test the
OpenVPN IPv6 payload stuff there?)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [Feedback needed] Fix cross compile support
Hi,
On Sun, Feb 28, 2010 at 10:25:10PM +0100, David Sommerseth wrote:
> I'm reviewing this patch in the patch tracker, and cannot make up my
> mind if this is correct or not. Can someone please advise if this is
> something we should include or not?
>
> <https://sourceforge.net/tracker/?func=detail&aid=2491190&group_id=48978&atid=454721>
I don't really understand the subtleties of autoconf and friends, but
I can attest that the current source tree cross-compiles just fine
(e.g. "configure --prefix=/usr --host=armv5tel-unknown-linux-gnueabi").
Something to keep in mind: changing all TARGET_* #ifdef's in the actual
code (as opposed to just changing the configure magic) *will* generate
lots of merge problems with the new feature branches. Especially the
IPv6 payload branch has lots of system dependent changes, so this part
of the change would have to be done in parallel on multiple branches,
causing the payload branch then to no longer apply to "base 2.1.1".
For this reason, I would NOT apply this patch right now - wait for the
development tree to stabilize, before applying a mostly-religious change
that affects 58 (!) places in the source.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] enhance tls-verify possibility
Hi,
On Sun, Feb 28, 2010 at 02:59:42PM +0100, David Sommerseth wrote:
> It should be nice to enhance tls-verify check possibilities against peer
> cert during a pending TLS connection like :
> - OCSP verification
> - check any X509 extensions of the peer certificate
> - delta CRL verification
> - ...
semi-ACK.
In general, I think this is useful.
Most of the code is fine, but I spotted a potential issue:
> @@ -896,6 +950,12 @@ verify_callback (int preverify_ok, X509_STORE_CTX * ctx)
>argv_msg_prefix (D_TLS_DEBUG, &argv, "TLS: executing verify command");
>ret = openvpn_execve (&argv, opt->es, S_SCRIPT);
>
> + if (opt->verify_export_cert)
> +{
> + delete_file(tmp_file);
> + gc_free(&gc);
> +}
> +
>if (system_ok (ret))
> {
> msg (D_HANDSHAKE, "VERIFY SCRIPT OK: depth=%d, %s",
tmp_file *could* be NULL here (unlikely, but possible).
So maybe this should read:
> @@ -896,6 +950,12 @@ verify_callback (int preverify_ok, X509_STORE_CTX * ctx)
>argv_msg_prefix (D_TLS_DEBUG, &argv, "TLS: executing verify command");
>ret = openvpn_execve (&argv, opt->es, S_SCRIPT);
>
> + if (opt->verify_export_cert)
> +{
> + if (tmp_file != NULL) delete_file(tmp_file);
> + gc_free(&gc);
> +}
> +
>if (system_ok (ret))
> {
> msg (D_HANDSHAKE, "VERIFY SCRIPT OK: depth=%d, %s",
... instead. "delete_file()" is one of the few functions that do not
check their argument for "is not NULL", so it's passed unchanged to
unlink(), which might cause issues on some platforms.
(Don't put the tmp_file condition into the surrounding if(), as it
would then skip the call to gc_free() as well).
With that change, and a manpage documentation of the new option, ACK.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] [PATCHv2] enhance tls-verify possibility
Hi, On Tue, Mar 02, 2010 at 12:31:41AM +0100, David Sommerseth wrote: > From: Mathieu GIANNECCHINI > > It should be nice to enhance tls-verify check possibilities against peer > cert during a pending TLS connection like : > - OCSP verification > - check any X509 extensions of the peer certificate > - delta CRL verification > - ... ACK. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Openvpn 2.1.1 bad tcp performance but good pingwhen -l 1472 (with packet size = MTU)
Hi, On Thu, Mar 04, 2010 at 09:28:48PM +0100, booyakasha wrote: > magic number 2952 (ping ?l 2952). It wasn?t only the 1472 ping > packet which worked OK. All packets over 2952 are OK !!! I am > waiting for your opinions why packets from 1 byte to 2952 bytes > (without 1472 byes package) are going extremely slowly and others not. TCP_NODELAY David has already suggested that you should try setting "socket-flags TCP_NODELAY" - did you? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Openvpn 2.1.1 bad tcp performance but good pingwhen -l 1472 (with packet size = MTU)
Hi,
On Thu, Mar 04, 2010 at 05:21:43PM -0600, open...@rkmorris.us wrote:
> I did this in the client configuration file ... is this right?
> I checked the OpenVPN web site, and it may be that I need this on
> the server side instead. Please clarify and I'll try it again (if
> I need to).
"socket-flags TCP_NODELAY"
that would need to go into both(!) config files - it changes the way the
operating system handles write() calls into a socket, that is, whether
the OS waits for "more data" to eventually generate a full sized packet,
or whether it will send the data immediately (generating a small packet).
(This is a fundamental problem with TCP - the stacks are optimized for
certain patterns, either "bulk data, make full size packets" or
"interactive traffic, send single bytes of keystrokes, where a few ms
delay don't hurt", but not for VPN-like traffic)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] special-case code for OpenBSD - advice needed
Hi,
On Fri, Mar 05, 2010 at 09:42:23AM +0100, Heiko Hund wrote:
> On Sunday 28 February 2010 15:50:01 Gert Doering wrote:
> > Now, for all operatings systems *except* Win32 and OpenBSD, the sequence
> > of execution is
> >
> > open_tun()
> > do_ifconfig()
>
> That seems to make sense for OpenBSD. I just had a colleague (kudos Moritz)
> try to connect with ifconfig_order() changed to
>
> static inline int
> ifconfig_order(void)
> {
> #if defined(WIN32)
>return IFCONFIG_BEFORE_TUN_OPEN;
> #else
>return IFCONFIG_AFTER_TUN_OPEN;
> #endif
> }
>
> and it broke the tunnel.
OK, this is interesting, and thanks a lot for testing.
What happened exactly? Could you ask your colleague for a log file?
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Openvpn 2.1.1 bad tcp performance but good pingwhen -l 1472 (with packet size = MTU)
Hi,
On Fri, Mar 05, 2010 at 09:42:17AM -0500, Michael H. Warfield wrote:
> Oh WOW... I hadn't even thought of that. That's got to be the A #1
> reason right there for avoiding the use of tcp like the plague for
> things like these.
>
> That means that OpenVPN is (to use the older terminology - I'm old
> school) not using the PUSH OOB method to push packets out and to get
> them received immediately at the other end. Looking that the
I'm not sure what OpenVPN *is* doing internally. I was just assuming that
the TCP_NODELAY (nagle) would affect performance for "half-full" packets
(as observed).
Since TCP_NODELAY is not having an effect here, it might be worth a look
into the sources to see that it's done correctly with TCP_PUSH.
*I* am not going to do that any time soon, though - I'm not using
VPN-over-TCP, and digging through the socket code of OpenVPN is fairly
far down on my "what to do with OpenVPN in my spare time" list.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] special-case code for OpenBSD - advice needed
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...
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] special-case code for OpenBSD - advice needed
Hi, On Fri, Mar 05, 2010 at 10:52:53AM -0600, Karl O. Pinc wrote: > > 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 This is what other platforms do, e.g. FreeBSD and Linux (on close, auto-destroy - and if you want persistance, you need to do something special). Maybe this was changed between older OpenBSD versions and the current versions? Given this information, I will prepare a patch that will handle OpenBSD the same way as FreeBSD is done - run open_tun() first, do_ifconfig() second, and do away with the "ifconfig destroy" logic. I'll send the patch to the list for testing. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] IPv6 support for TUN/TAP driver on windows
Hi,
On Sun, Feb 28, 2010 at 11:23:26PM +0100, Gert Doering wrote:
> to follow up on this...
Next round of "do things on windows" :-)
> [ TUN / TAP driver on windows ]
>
> Now... is there someone who has worked on this before, and can help
> me a bit with it?
>
> Initial questions:
>
> - can it be cross-compiled? If yes, how? If no, what needs to be
>done on Windows to compile it? (I have *no* experience with Windows,
>but I can follow instructions and read documentation).
It does not seem to be possible to cross-compile this.
For the archives:
Fairly detailed instructions how to compile on windows are contained in
"domake-win" in the OpenVPN distribution - unfortunately, this is lacking
some of the important details, like "what to do if Microsoft is not willing
to ship WDK 6001* anymore, but you need to adjust to 7.1.0" or "don't
even try to build this from a drive that is not C:".
Anyway:
- get MinGW and MSYS
- get the Windows Driver Kit (WDK) from Microsoft
- put everything on C:, not on different drive letters(!!)
- follow the instructions in domake-win
- adjust install-win32/settings.in if you use a different WDK version
- adjust install-win32/maketap, "w2ktarget=..." for current WDK versions
- build, pray, curse, fix scripts, ...
So far, I have been successful in building the tap driver, and ignored
all the rest. I will give this another fight on a machine with enough
disk space on C: next week.
> - what needs to be done to install the driver / replace the existing
>driver?
If you have OpenVPN installed in the normal location, just copy the
driver sources (tap0901.sys, tap0901.cap, OemWin2k.inf) to
C:\...\openvpn\driver and run "deltapall.bat" and "addtap.bat" from
...\openvpn\bin.
Make sure OpenVPN isn't active while replacing the driver, because you
might end up using the driver that's still in memory.
> - how does one debug Windows drivers? Is there a printf() as in Linux
>that goes to console / syslog?
I have not yet figured out that part. I did my debugging with Wireshark
("see what packets move back and forth and stare at the packet details").
Attached below is the patch to the TUN/TAP driver that is required to
make OpenVPN work with IPv6 in TUN mode on windows. The magic for IPv6
is modelled similar to the way ARP is handled for IPv4:
- all routes are set up with a next-hop of fe80::8
- if the tapdrvr notices a neighbor-discovery packet for fe80::8, it
will grab the packet and synthesize a neighbor-advertisement response
- windows is happy and sends the data packets to the tap driver :-)
(The patch is 175e17a5abd5969f6803a9cc9587b7959e1100ae in my git tree
- David, could you please git-pull to feat_ipv6_payload?)
What needs to happen next?
- "someone who understands" needs to look at the diff, and ACK it
(or tell me where i misunderstood things, and what to fix)
- 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
- if someone is willing to risk the stability of his system, you can
test my binaries:
http://www.greenie.net/ipv6/tap0901-ipv6-20100307.tar.gz
http://www.greenie.net/ipv6/openvpn-win-ipv6-20100307.tgz
(extract in ...\openvpn\driver and ...\openvpn\bin, respectively,
then run deltapall.bat / addtap.bat)
DO NOT DO THIS ON A PRODUCTION SYSTEM. Really. This has been tested
on two different Windows XP systems, and no adverse effects have been
observed - but this is my first attemt at Windows driver programming,
and I would not trust that yet.
gert
diff --git a/install-win32/settings.in b/install-win32/settings.in
index 643ef99..202f782 100644
--- a/install-win32/settings.in
+++ b/install-win32/settings.in
@@ -42,8 +42,8 @@
!define PRODUCT_TAP_DEVICE_DESCRIPTION "TAP-Win32 Adapter V9"
!define PRODUCT_TAP_PROVIDER"TAP-Win32 Provider V9"
!define PRODUCT_TAP_MAJOR_VER 9
-!define PRODUCT_TAP_MINOR_VER 6
-!define PRODUCT_TAP_RELDATE "06/22/2009"
+!define PRODUCT_TAP_MINOR_VER 7
+!define PRODUCT_TAP_RELDATE "07/03/2010"
# TAP adapter icon -- visible=0x81 or hidden=0x89
!define PRODUCT_TAP_CHARACTERISTICS 0x81
diff --git a/tap-win32/proto.h b/tap-win32/proto.h
index e059772..ffb9ac9 100755
--- a/tap-win32/proto.h
+++ b/tap-win32/proto.h
@@ -29,9 +29,11 @@
#pragma pack(1)
#define IP_HEADER_SIZE 20
+#define IPV6_HEADER_SIZE 40
typedef unsigned char MACADDR [6];
typedef unsigned long IPADDR;
+typedef unsigned char IPV6ADDR [16];
//-
// Ethernet address
@@ -55,6 +57,7 @@ typedef struct
MACADDR src;/* source ether addr */
# def
Re: [Openvpn-devel] [PATCH] IPv6 support for TUN/TAP driver on windows
Hi,
On Sun, Mar 07, 2010 at 09:47:17PM +0100, Peter Stuge wrote:
> Gert Doering wrote:
> > -!define PRODUCT_TAP_RELDATE "06/22/2009"
> > +!define PRODUCT_TAP_RELDATE "07/03/2010"
>
> Seems month/date are swapped.
Stupid american date formats. In my build tree, this is actually
correct, but the commit was done on the unix host.
Thanks for pointing this out - change to "03/07/2010" committed.
(Not that *this* would really matter, as I assume that OpenVPN Tech
is going to keep their hand on defining release dates and driver
versions :-) ).
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] IPv6 support for TUN/TAP driver on windows
Hi,
On Mon, Mar 08, 2010 at 09:00:14AM -0700, James Yonan wrote:
> >I have not yet figured out that part. I did my debugging with Wireshark
> >("see what packets move back and forth and stare at the packet details").
>
> While Windows doesn't support "printf" in device drivers, the TAP driver
> defines the DEBUGP macro that tries to do the same thing.
I've seen these, but was missing the next steps - "how do I get to read
these messages".
[..]
> Next, there are two possible ways to view the debugging output:
>
> Get the WinDBG tool from MS. All of the DEBUGP calls will output log
> info in a form that can be received by WinDBG.
Will check that. There are "some debuggers" as part of the WDK, but I
have not yet looked into these in more detail.
> Use a special feature of OpenVPN on Windows that allows it to get the
> DEBUGP messages directly from the TAP driver and output them along with
> the normal OpenVPN log output. This feature is enabled at --verb level
> 6 and is internally referred to as D_TAP_WIN32_DEBUG in errlevel.h.
Now THAT is seriously cool :-)
I have seen that the code writes the debug messages "to a buffer", but
couldn't find out (yet) how to access the debug messages.
Thanks a lot for this. I will use this information to improve the debug
printing of IPv6 packets (which is non-existant yet) and also add a bit
of debug printing to the code that does neighbor discovery / neighbor
advertisement spoofing, so it's visible in the logs what happens and
why.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows
Hi,
looking at the multitude of DHCP clients available for unix, the completely
different handling of DHCP on MacOS, and the issues that most unix clients
seem to have with "DHCP active on two different interfaces (ethX and tapY),
and both trying to set a default gateway", ...
On Mon, Mar 08, 2010 at 08:21:35AM -0700, James Yonan wrote:
> (2) Complex method: Write code in OpenVPN to simulate a DHCP client,
> then translate the settings received in the DHCP reply to OpenVPN
> push-style directives (such as ifconfig, route, etc.) as if they had
> been pushed by the OpenVPN server.
... this seems to be the most portable way, as we already have the
ifconfig/route code for all the platforms.
Well. Let me rephrase.
The "simple way" is simple as far as the packet flow inside OpenVPN
goes (because OpenVPN only needs to transport packets, but not generate
them or parse them), but is, at the same time, the "most complex way"
as far as getting it to work reliably across all supported operating
systems. Lots of testing and "configure" magic would be necessary to
reliably figure out how to do DHCP properly on each individual system.
I'm not saying it can't be done :-) - but just that the "simple way"
is not so simple, it's just complex in other places.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows
Hi,
On Wed, Mar 10, 2010 at 10:52:00PM +, Timothy Baldwin wrote:
> James Yonan wrote:
>
> > Implementing a DHCP client within OpenVPN tends to make this a more
> > self-contained problem.
>
> But what about IPv6, tunnels and DHCP prefix delegation?
IPv6 is a separate issue. The current IPv6 payload patch supports
"IPv6 ifconfig pool" and ccd/-based static IPv6 assignment on the server
side (pushing "ifconfig-ipv6" to the client), or static configuration
on client and server side.
The configuration of IPv6 on the interface is done with the distribution-
specific methods (ifconfig, ip -6 addr, netsh, ...)
IPv6 prefix delegation is something OpenVPN currently doesn't do at all -
neither with a server-based configuration, nor with DHCP PD.
For TAP interfaces (what this discussion was about for IPv4), DHCP PD
could be made to work without assistance from OpenVPN - because OpenVPN
only sees ethernet frames anyway. For TUN interfaces, OpenVPN would need
to understand DHCP PD and act as a DHCP relay router - otherwise, OpenVPN
wouldn't know how to install the necessary iroute6 towards the client
that has been delegated a prefix. But this is all "future plans" - first,
get the current IPv6 payload stuff tested well enough that it can get
integrated in the next beta :-)
> Invoking the distribution auto-configuration/ scripts makes more sense.
It doesn't. For the same reasons as with IPv4.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows
Hi, On Thu, Mar 11, 2010 at 04:10:23PM +0100, David Sommerseth wrote: > In my point of view, it's more important to find a solution which will > be easy to maintain in the OpenVPN code and which doesn't give a > headache to the package maintainers or system admins needing to > configure OpenVPN. Seconded. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows
Hi,
On Thu, Mar 11, 2010 at 05:07:29PM +0100, Jan Just Keijser 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.
The question is, *where* will it be?
a) figuring out how to properly run the system's DHCP client [which might
not even be installed] for *this* version of Linux or FreeBSD or
OpenBSD or NetBSD or Solaris or MacOS in the right way
b) contain the code to generate a DHCP request (trivial) and parse the
response (fairly trivial), and use the already-existing IP configuration
and route-setup bits
For people that only know their small local operating system island,
"a)" seems like a trivial task. For software that is so highly portable
as OpenVPN, "a)" is a truckload of pain.
I have been through the pain in implementing IPv6 support for all
operating systems (except OpenBSD yet) that OpenVPN supports - and that
was harmless in regard to the variety of DHCP clients that exist and
all of them need to be twiddled and poked in different ways, most of them
*way out of control of OpenVPN*.
This might be the other big misunderstanding here. As of today, if you
want to use "ifplugd + dhcp + ..." on a TAP interface, just do so - OpenVPN
won't stand in your way. This is not the issue at hand - the issue is
that OpenVPN wants to be friendly to the users, and give them an option
to do DHCP-on-TAP without(!) having to fiddle with their local network
setup.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows
Hi, On Thu, Mar 11, 2010 at 05:42:07PM -0500, 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. In that case it might be helpful to read the mail from James Yonan that started this thread. > 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. This is the trivial bit. [..] > I find the effort would be better spent on working with other people > trying to make sure that ifplugd/NetworkManager/distributions/... make > this setup as troublefree as possible. E.g. make sure that ifplugd > works well with tap devices (e.g. that it tries to handle them by > default) and that NetworkManager can easily use OpenVPN and correctly > (re)starts dhcp clients for the corresponding tap devices. The world is a bit larger than "Linux distributions having ifplugd". OpenVPN runs on Linux, 5 different *BSD variants, Solaris, MacOS X and Window - and it's not OpenVPN's job to fix the local equivalent of ifplugd on each of these systems. OpenVPN's aim is to provide an easy-to-use VPN environment for people that do not want to endlessly fiddle with operating system settings. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
[Openvpn-devel] [bb...@dream2cook.com: Re: [PATCH] IPv6 support for TUN/TAP driver on windows]
Hi,
forwarded with permission from Ben back to the list - another data
point: a successful test of the IPv6-patched windows binaries and
windows tap driver, on Windows XP.
More testers with Vista and Win7 needed :-)
gert
- Forwarded message from Ben Bird -
X-Spam-Status: No, score=-2.6 required=7.0 tests=BAYES_00 autolearn=no
version=3.2.5
From: Ben Bird
To: Gert Doering
Subject: Re: [PATCH] IPv6 support for TUN/TAP driver on windows
List-Post: openvpn-devel@lists.sourceforge.net
Date: Thu, 11 Mar 2010 16:45:24 -0700
Reply-To: bb...@dream2cook.com
In-Reply-To: <20100307201731.gt25...@greenie.muc.de>
X-Mailer: Forte Agent 5.00/32.1171
X-Greylist: Delayed for 00:23:20 by milter-greylist-4.2.3 (delta2.greenie.net
[194.97.144.211]); Fri, 12 Mar 2010 01:15:59 +0100 (CET)
X-Virus-Scanned: clamav-milter 0.95.3 at deltaii.greenie.net
On Sun, 7 Mar 2010 21:17:31 +0100, in gmane.network.openvpn.devel you wrote:
...
> - if someone is willing to risk the stability of his system, you can
> test my binaries:
>
>http://www.greenie.net/ipv6/tap0901-ipv6-20100307.tar.gz
>http://www.greenie.net/ipv6/openvpn-win-ipv6-20100307.tgz
>
> (extract in ...\openvpn\driver and ...\openvpn\bin, respectively,
> then run deltapall.bat / addtap.bat)
>
Hi Gert,
I'm not a subscriber. So, I can't reply to the list. I follow it on
gmane.org's NNTP relay.
Just wanted to say thanks for all your efforts here, and let you know I am glad
to risk it. :) I'm running your tap driver with success on winxp.
Ethernet adapter Local Area Connection 4:
Connection-specific DNS Suffix . : home.dream2cook.com
Description . . . . . . . . . . . : TAP-Win32 Adapter V9
Physical Address. . . . . . . . . : 00-FF-1B-05-0E-17
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.110.6
Subnet Mask . . . . . . . . . . . : 255.255.255.252
IP Address. . . . . . . . . . . . : 2001:470:80d5:1::7 <---
woot!
IP Address. . . . . . . . . . . . : fe80::2ff:1bff:fe05:e17%8
Default Gateway . . . . . . . . . : fe80::8%8
DHCP Server . . . . . . . . . . . : 192.168.110.5
DNS Servers . . . . . . . . . . . : 192.168.1.1
208.67.220.220
fec0:0:0:::1%1
fec0:0:0:::2%1
fec0:0:0:::3%1
Lease Obtained. . . . . . . . . . : Thursday, March 11, 2010 16:30:38
Lease Expires . . . . . . . . . . : Friday, March 11, 2011 16:30:38
C:\Documents and Settings\benb>ping6 www.greenie.net
Pinging delta2.greenie.net [2001:608:0:1007:a00:20ff:fefe:4bd2]
from 2001:470:80d5:1::7 with 32 bytes of data:
Reply from 2001:608:0:1007:a00:20ff:fefe:4bd2: bytes=32 time=230ms
Reply from 2001:608:0:1007:a00:20ff:fefe:4bd2: bytes=32 time=226ms
Reply from 2001:608:0:1007:a00:20ff:fefe:4bd2: bytes=32 time=226ms
Reply from 2001:608:0:1007:a00:20ff:fefe:4bd2: bytes=32 time=228ms
Ping statistics for 2001:608:0:1007:a00:20ff:fefe:4bd2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 226ms, Maximum = 230ms, Average = 227ms
C:\Documents and Settings\benb>
Regards,
Ben
- End forwarded message -
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Compiling openvpn for windows using mingw32
Hi, On Sun, Mar 14, 2010 at 02:47:32AM -, Kill AllSnoopers wrote: > I am trying to compile openvpn for windows using mingw32 and have openssl > lzo, etc compiled. I am trying to compile to create the openvpn.exe and then > use the GUI. Are you trying to compile natively, or cross-compile? > I haven't figured how to compile the main openvpn to create openvpn.exe > > The instructions on openvpn are not that helpful for this part. > > Can anyone outline the steps or point to mails in the forum that discuss > it. I did a search for them without any useful results. To cross-compile, use Alon's "Build" script, http://opensc-project.org/build on top of a Linux system of your choice. To download the script itself, go to "http://www.opensc-project.org/build/browkser/trunk/build"; and then click on "download in other formats: plain text" at the end. If you want to compile natively on windows, install mingw + msys, and then follow the instructions in "domake-win" in the OpenVPN source tree (it's the script to run, and it has lots of documentation inside how to get the required components). Building for Windows is not something for the faint of heart, or for unexperienced package builders. Expect build failures, and expect to read other people's scripts and figure out what is failing and what you need to add to your build environment to make it work. If you ask this list, better include a full description of what you did, on which platform, and what error message resulted - otherwise we're not able to give useful advice. (Out of personal curiousity: why are you trying to build-your-own? The precompiled packages work perfectly well...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [Feedback needed] Fix cross compile support
Hi, On Sun, Mar 14, 2010 at 12:13:26AM +0100, Matthias Andree wrote: > No offense, but do you think it's within objective discussion to call the > patch > "mostly-religious change" (which is a non-objective comment in my book) if you > "don't really understand the subtleties of autoconf and friends"? Well, there's two parts to the original patch. One is the functional patches in configure.ac - I can't say anything about that, so I'm not doing so. The other part is changing all TARGET_* defines to HOST_* defines. This is not changing functionality or portability, as the very defines are explicitely set in configure.ac, and they could be MySystemIs_* as far as functionality is concerned. So the change is because people believe it to be "the right way" - which makes it "mostly-religious" in my book: not based on functional changes, but because "it's the right way". Whitespace changes to cleanup broken formatting fall into the same category for me - quite often, there are very good reasons to do so, but if the circumstances are such that it conflicts with other development work, it might be prudent to postpone them until after other stuff has been merged. ... and this is exactly what I proposed: don't include the larger chunk of the changes right *now*. Wait for the multiple branches to settle down, and then decide how to adjust the TARGET_* definitions. [..] > WRT practical merge concerns around TARGET_*, git knows the "rerere" > sub-command > to track merge conflict resolutions (see the manual); and since the required > edits can be scripted, that could happen on the feature branches before > attempting a merge. No big deal. Well, this is putting extra work on David Sommerseth's lap. If he is willing to handle that, I won't object. As for now, I have been operating under the premises that different branches in the openvpn-devel tree should avoid to cause merge conflicts (unless unavoidable for required functionality, see ipv6 payload vs. ipv6 transport). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [Feedback needed] Fix cross compile support
Hi,
On Sun, Mar 14, 2010 at 12:26:58PM +0100, Matthias Andree wrote:
> > ... and this is exactly what I proposed: don't include the larger chunk
> > of the changes right *now*. Wait for the multiple branches to settle
> > down, and then decide how to adjust the TARGET_* definitions.
>
> Which is a valid technical reason (as much as "use proper names" is).
Good to see some understanding here. I really didn't want to get into
a religious fight here, about me calling certain decisions "religious" :-)
> I was trying to keep religion out though :)
Given the amount of religous discussions about OpenSource stuff, this
is a very reasonable point of view ;-)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
[Openvpn-devel] Windows, OpenVPN-GUI, disconnect
Hi, can one of you tell me what happens "under the hood" if I click the "disconnect" button of the openvpn-gui under Windows XP? Why am I asking? I managed to get my windows build environment working well enough that I can now build a complete installer package with the IPv6 patches, and with the adapted tun/tap driver - but it breaks in funny ways. - Installation works fine - running the openvpn-gui (precompiled) works fine - (client) connection to a TUN server works fine [initiated by pressing the "connect..." button of the GUI in the windowsstatus bar] - IPv4 and IPv6 connectivity works - pressing the "disconnection" button of the GUI doesn't seem to do anything. Well, the status window says "disconnecting..." and the button is greyed out - but no update in the log file or the status window, no nothing. I assume that "something is miscompiled" or "a newer version of mingw has some surprising side effects" - but to know where to start looking, it would be helpful to understand what signalling is used openvpn-gui --> openvpn.exe to signal disconnect. (Since I didn't touch any of the signal handling stuff, I'm fairly sure that it wasn't one of my changes, but I still want to have a working Windows bundle to get people to test it) thanks, gert PS: the TAP driver changes have been successfully tested on 3 different WinXP systems now. Win7 doesn't work "as is", as it requires a signed driver. -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpxZVlmr0KDP.pgp Description: PGP signature
Re: [Openvpn-devel] Windows, OpenVPN-GUI, disconnect
Hi, On Thu, Mar 18, 2010 at 01:14:22PM +0100, Jan Just Keijser wrote: > took me a while to figure this one out: > the openvpn gui codes sets an 'exit event' (using a win32 API call > CreateEvent) before starting the actual openvpn process; when the user > chooses 'disconnect' this 'exit event' is triggered, which causes the > process to be terminated (using the appropriate win32 signal). Huh, scary stuff. How would that win32 signal be delivered to the openvpn.exe process? Will it just receive a unix-like signal "SIGTERM"? Or does it have to poll some sort of Windows event queue? BTW: I just discovered that this is not limited to the openvpn.exe I built *on* windows, but that my linux-mingw crosscompiled openvpn.exe does this as well now, and so does the original OpenVPN-provided 2.1.1 binary(!). "Something weird happened to this machine", and I don't understand what it is. > The question now becomes: what does openvpn do when it receives a > terminate signal? actually, is there a signal being sent to the server > to say "client X is disconnecting" ? Nothing whatsoever visible in the logs. The last entry in the log (verb 5) is after successful startup: "Initialization Sequence Complete" ... and then when pressing , nothing whatsoever happens. The OpenVPN connection stays alive and healthy(!), packets continue to get forwarded, just the signal delivery fails. (If I increase the log verbosity to "verb 9", lots of stuff is going on, but nothing in there that gives any indication of signals being received) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Windows, OpenVPN-GUI, disconnect
Hi, On Thu, Mar 18, 2010 at 03:18:19PM +0100, Eike Lohmann wrote: > On win7 with baloontips disabled you can connect but can't disconnect > via the gui. > Maybe that's your problem? Now that's an interesting information. I'm on WinXP, so it's not the same issue - but to see someone else having problems with "disconnect" is interesting, so it might not be related to my build at all. Mmmh. More testing. All this on WXP with the latest updates installed. a) remove all OpenVPN stuff, reboot, reinstall unmodified 2.1.1 -> connect/disconnect works fine b) from there, deltapall / addtap the IPv6 capable tap driver, but stil use all the unmodified .exe -> connect/disconnect works fine c) reboot, try again (unmodified .exe, IPv6-capable tap driver) -> connect/disconnect works fine d) replace openvpn.exe + SSL DLLs with compiled-on-mingw/linux IPv6-capable binaries, connect to IPv4-only tunnel server -> connect fine/disconnect FAIL e) copy unmodified binaries + DLL back -> connect/disconnect works fine f) replace openvpn.exe with compiled-on-mingw/windows IPv6-capable binary, connect to IPv4-only tunnel server -> connect fine/disconnect FAIL ... so it's definitely something in the binaries that I have built that makes disconnect fail, but it doesn't matter whether I compile the binary on Linux or on Windows. It's *not* related to TAP-driver changes (which is an important bit). When running openvpn.exe from the "cmd.exe" command line, it does not matter which binary I am using - "ctrl-c" never does anything, and "F4" always causes a clean shutdown. Weird, this. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [Fwd: Re: Clarifications to "OpenVPN will not connect through certain HTTP proxies" bug report]
Hi,
On Mon, Mar 22, 2010 at 03:57:52PM +0200, Samuli Seppänen wrote:
> I encountered this with T-mobile's t-zones web proxy. I haven't
> needed to use it lately, so I can't verify that the patch is still
> necessary. I don't know of any proxy servers that won't accept the
> http:// prefix, especially if the port number is 443.
As tested: this syntax neither works with Squid nor Apache.
So I'd tend to agree with David: if a single user had a problem with
a T-Home proxy in 2007, I'd tend to blaim the proxy.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Make use of counter_type instead of int when counting bytes and network packets
Hi,
On Thu, Apr 08, 2010 at 09:22:54PM +0200, David Sommerseth wrote:
> This is in response to a reported Debian bug, where the connection
> counter overflows.
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576827>
[..]
> {
> - msg (D_TLS_DEBUG_LOW, "TLS: soft reset sec=%d bytes=%d/%d pkts=%d/%d",
> + msg (D_TLS_DEBUG_LOW,
> + "TLS: soft reset sec=%d bytes=" counter_format "/%d pkts="
> counter_format "/%d",
> (int)(ks->established + session->opt->renegotiate_seconds - now),
[..]
> - int n_bytes;/* how many bytes sent/recvd since
> last key exchange */
> - int n_packets; /* how many packets sent/recvd since last key
> exchange */
> + counter_type n_bytes; /* how many bytes sent/recvd since
> last key exchange */
> + counter_type n_packets; /* how many packets sent/recvd since last key
> exchange */
ACK, this looks good. The "counter_type" and "counter_format" infrastructure
will give 64-bit counters with portability to whatever systems supports
64 bit - and fallback to 32 bit where it is not possible.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Add comile time settings from ./configure information to --version
Hi, On Tue, Mar 30, 2010 at 02:12:58PM +0200, David Sommerseth wrote: > This patch will create ./configure.h which will contain two new #define > strings. CONFIGURE_DEFINES will contain all USE, ENABLED, DISABLED and > DEPRECATED defines from ./config.h. CONFIGURE_CALL will contain the > complete ./configure line which was used when configuring the package > for building. A bit late, but "looks good to me" (and useful, too :) ). ACK. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH 4/9] vlan: Prepend and remove VLAN identifiers on outgoing and incoming frames
Hi,
On Thu, Apr 01, 2010 at 10:59:05AM +0200, Jan Just Keijser wrote:
> > Hm, nice idea. I'll implement it in my next round of patches.
> >
> FYI: 802.1Q defines VLAN 1 as the 'native' LAN: all packets on VLAN 1
> are *by definition* not encapsulated (according to my CCNA guide ;-))
> VID 0 means "priority frames"
> Perhaps we need to make sure that VID 1 means untagged ...
Different vendors handle this differently - on Cisco, for example,
you can make vlan 1 tagged and have the "native" VLAN on a port
(= untagged transmissions) on a different VID.
So you can't rely on "VID 1 = untagged".
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH 4/9] vlan: Prepend and remove VLAN identifiers on outgoing and incoming frames
Hi,
On Thu, Apr 01, 2010 at 01:49:02PM +0200, David Sommerseth wrote:
> >From a security and not the least from a performance perspective, the
> OpenVPN clients should only receive traffic which hits it's own VLAN
> (ie. the server does the "filtering" before sending data to the client).
> I'm not sure if I saw this in code or not ... but if it is in place and
> somebody could point me to the patch which does it, I would be happy.
The patch description (part 0) says so:
- snip ---
Packets coming in from the TAP device are assumed to be tagged with
IEEE 802.1Q headers. OpenVPN removes the tag, remembers the VID and
routes the packet to the destination client(s) on the other side of the
secure tunnel which have a matching VID.
- snip ---
I have not yet reviewed the source to check whether this really takes
place.
Something else I need to check: the "standard" mroute code hashes based
on ethernet address (in tap mode). What happens if the same MAC address
shows up for two different VLAN IDs? (Not very likely for virtual
ethernet devices, though, but this can happen in real-world scenarios).
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Harden create_temp_filename()
Hi, On Fri, Apr 16, 2010 at 11:16:32AM +0200, David Sommerseth wrote: > I'll look more into this, as the only advantage is that if open() with > O_EXCL|O_CREAT fails if the file exists, it should be used instead. Unfortunately, this won't help against symlink attacks directed to non-existant files (like "-> /etc/nologin"). It *will* protect against symlink attacks to existing files (overwriting /etc/passwd or something similarily nasty). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Harden create_temp_filename()
Hi,
On Fri, Apr 16, 2010 at 11:02:34AM +0100, Davide Brini wrote:
> > Unfortunately, this won't help against symlink attacks directed to
> > non-existant files (like "-> /etc/nologin").
>
> "If O_EXCL and O_CREAT are set, and path names a symbolic link, open() shall
> fail and set errno to [EEXIST], regardless of the contents of the symbolic
> link."
Oh? One learns something new every day :-) - just checked with the FreeBSD
manpage, and it's even more explicit:
If O_EXCL is set and
the last component of the pathname is a symbolic link, open() will fail
even if the symbolic link points to a non-existent name.
- so please disregard my comment. Everything is fine.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH 2/2] Fixed potential NULL pointer issue
Hi, On Sat, Apr 17, 2010 at 09:06:09PM +0200, David Sommerseth wrote: > If create_temp_file() returns NULL, this strlen() check would cause > a SEGV. Looks "obviously correct". ACK. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCHv2 0/3] Harden create_temp_filename()
Hi,
On Fri, Apr 16, 2010 at 10:21:50PM +0200, David Sommerseth wrote:
> In a Debian bug report [1] there were worries that the --client-connect
> script hook was prune to a "symlink" attack. Even though this can
> be recognised if --tmp-dir is set to a world writable directory, it is not
> considered standard practice to do so.
>
> This patch-set replaces the previous suggested patch, with an enhancement
> suggested by Fabian Knittel. In addition create_temp_filename() is renamed
> to create_temp_file() to reflect the behvioural change in the function.
Overall, this looks good to me (with the additional changes by Fabian
and you). So ACK.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] TAP interface support for Solaris/OpenSolaris
Hi, On Thu, Apr 29, 2010 at 01:02:37PM +0900, Kazuyoshi Aizawa wrote: > I've attached a patch for tun.c which includes support for tap > interface for solaris/opensolaris. > The code is based on OpneVPN 2.1.1. And it has a routine to > plumb/unplumb tap interface like ifconfig command. > > tap driver for solarsi/opensolaris is here: > http://www.whiteboard.ne.jp/~admin2/tuntap/ Thanks for your work!. I have already used bits from there when adding IPv6 payload support to OpenVPN on Solaris :-) Question to the community: how do we want to integrate the tun.c changes for Solaris? Its own branch, feat_misc branch, feat_ipv6_payload branch? If we include it in feat_ipv6_payload, it won't have merge conflicts - but then you only get the TAP-on-Solaris in combination with all the IPv6 stuff, which people might not want. David? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] TAP interface support for Solaris/OpenSolaris
Hi again,
On Thu, Apr 29, 2010 at 01:02:37PM +0900, Kazuyoshi Aizawa wrote:
> I've attached a patch for tun.c which includes support for tap
> interface for solaris/opensolaris.
I've glanced through the patch, and there's also changes in the Win32
part of the tun.c, for example this chunk:
--- quote --
@@ -,19 +3409,19 @@
bool ret = false;
const IP_ADAPTER_INDEX_MAP *inter = get_interface_info (adapter_index, &gc);
- if (inter)
-{
- DWORD status = IpRenewAddress ((IP_ADAPTER_INDEX_MAP *)inter);
- if (status == NO_ERROR)
+ if (inter)
{
- msg (D_TUNTAP_INFO, "TAP: DHCP address renewal succeeded");
- ret = true;
+ DWORD status = IpRenewAddress ((IP_ADAPTER_INDEX_MAP *)inter);
+ if (status == NO_ERROR)
+ {
+ msg (D_TUNTAP_INFO, "TAP: DHCP address renewal succeeded");
+ ret = true;
+ }
+ else
+ msg (M_WARN, "WARNING: Failed to renew DHCP IP address lease on
TAP-Win32 adapter: %s (code=%u)",
+strerror_win32 (status, &gc),
+(unsigned int)status);
}
- else
- msg (M_WARN, "WARNING: Failed to renew DHCP IP address lease on
TAP-Win32 adapter: %s (code=%u)",
-strerror_win32 (status, &gc),
-(unsigned int)status);
-}
gc_free (&gc);
return ret;
}
--- quote --
>From a first glance, this looks like "whitespace changes only".
For easier review: would you be so kind and re-send your patch with
"diff -uw" (-w = ignore white space changes)?
thanks,
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] TAP interface support for Solaris/OpenSolaris
Hi, On Thu, Apr 29, 2010 at 04:39:35PM +0900, Kazuyoshi Aizawa wrote: > Thank you for your support. > Please find attached patch with diff -uw. Thanks. I wouldn't claim to understand why the specific changes are needed, but this way it is obvious that the changes really only affect the Solaris-specific part of tun.c. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] TAP interface support for Solaris/OpenSolaris
Hi,
On Thu, Apr 29, 2010 at 10:03:23AM +0200, David Sommerseth wrote:
> > If we include it in feat_ipv6_payload, it won't have merge conflicts - but
> > then you only get the TAP-on-Solaris in combination with all the IPv6 stuff,
> > which people might not want.
> >
> > David?
>
> You seem to have pretty well good control over this TUN/TAP
> infrastructure. So I have no problems with you pulling whatever you
> find useful into your IPv6 branch, which covers this.
OK, if nobody objects, I'll integrate the rest of these patches into
"my" tun.c, and commit to the IPv6 payload branch. (Will take a few
days...)
If someone urgently needs TAP support for Solaris later on, but refuses
to use the IPv6 stuff, we can still sort out what to do then.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [Openvpn-users] [TESTING NEEDED] Using --inactive and --ping seems to defeat each other
Hi, On Fri, Apr 30, 2010 at 06:24:20PM +0100, Davide Brini wrote: > Well, the obvious (and probably wrong, probably inefficient) way could be to > just check if the packet at hand is a ping message, and if it is do not > record > it as "activity", eg > > if (! is_ping_msg (&c->c2.buf)) >register_activity (c, size); Looks good to me :-) (without having looked at the code in question at all). > This is in two places: in process_outgoing_tun() and process_outgoing_link(). As you wrote in the next e-mail, this won't ever be "outgoing on tun", so only one place needs changing... > However, I'm not sure about the overhead of performing that for each and > every > processed packet. is_ping_msg() calls buf_string_match(), which in turn calls > memcmp(). > But, it should also be noted that process_incoming_link() DOES call > is_ping_msg() for every incoming packet, so... I'm a big fan of symmetry here - if the incoming packet path explictly not-counts ping packets, it's a bit hard to explain to users why the outgoing packet path *does* count them, and they have to fiddle with byte counts to get "inactivity". I'd go that route... Efficiency is a valid concern, of course. Since is_ping_msg() and buf_string_match() are both (very short) inline functions, and memcmp() on "normal" architectures is also inlined by gcc, this "should not" add unduly overhead. (Of course, down that road is hell and windows vista). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Re: Handling of subnets grammar in Packet filter file
Hi,
On Thu, Jun 03, 2010 at 04:48:35PM +0200, chantra wrote:
> Please find below a patch to correct the behaviour.
>
> I have also opened a trac ticket :
> https://community.openvpn.net/openvpn/ticket/14
The patch itself looks good.
It's a bit of a philosophical issue what to do with network specifications
given like this - one approach would be to *reject* as a config error
("a /28 network cannot start at .8"), the other approach is what you have
done, to silently mask out the host bits, changing the .8/28 to .0/28.
Both have merits, your fix is somewhat less code then adding an extra input
validation check
if ((network.s_addr & netmask) != network.s_addr )
{ complain; }
- so: ACK from me.
(Since OpenVPN likes to print warnings, we *could* add code to print a
warning in this case - "warning: subnet address changed to match /%d,
new value is %s/%d").
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Re: Handling of subnets grammar in Packet filter file
Hi, On Thu, Jun 03, 2010 at 12:47:47PM -0500, Eric F Crist wrote: > > I upated the patch and it will now display something like: > > WARNING: PF: /dev/shm/openvpn_pf_ff18e7030fd03ce91bd0432563e4eb1a.tmp/5: > > incorrect subnet 192.168.100.8/28 changed to 192.168.100.0/28 > > This seems rather pedantic to me... Well, it is, but it's in line with the rest of OpenVPN - there are many places where a (percieved) user error results in a warning, explaining the situation... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Choose a different field in X509 to be username
Hi, On Fri, Jun 18, 2010 at 02:01:20AM +0200, Peter Stuge wrote: > David Sommerseth wrote: > > > 3) "sizeof(common_name)" is useless... Line 745: char > > > common_name[TLS_USERNAME_LEN]; we can use directly TLS_USERNAME_LEN. > > > > Thanks a lot for the patch and all rework done. (Also: thank you to all > > reviewers!) > > > > The third and last patch looks very good! I've applied it to the > > feat_misc branch and merged it into allmerged. > > I strongly agree with Alon about sizeof() rather than a second > reference to the same define. It is the defensive way. I'm a bit late, but I also want to second this :-) That way, if the definition of "common_name" is ever changed to a different size, e.g "TLS_USERNAME_LEN+3" or whatever, all(!) references automatically get the correct size. Defensive coding, less surprises later on. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [Openvpn-users] Is it possible to access Windows XP shares over port 445?
Hi,
On Wed, Jun 23, 2010 at 09:10:10AM +0200, Jan Just Keijser wrote:
> assigns a 169.254 address. If this works for you as well then maybe the
> tap-win32 developers can dive deeper into this and find out why windows
> treats the 'always connected' adapter differently from an 'application
> controlled' adapter .
I'd assume that windows services are not "bound" to "dynamic" interfaces...
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Debian package of feat_allmerged
Hi,
On Fri, Jun 25, 2010 at 01:27:35AM +, Bernhard Schmidt wrote:
> I have just restarted building Debian/Ubuntu OpenVPN packages for the
> feat_allmerged branch of openvpn-testing.git for my private use.
Cool!
> I will try to automate rebuilding packages on git updates if someone is
> interested in them.
Yes, that would be useful, to make sure we get as much testing for this
stuff as possible. Lots of testing -> easier & quicker integration into the
"master" source.
If it's not too much effort, having binary packages for the 2.2_beta
branch (which David will have "soonish" :) ) would be great as well.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [Openvpn-users] Is it possible to access Windows XP shares over port 445?
Hi, On Wed, Jun 23, 2010 at 10:50:45PM +0300, Henno Täht wrote: > On Wed, Jun 23, 2010 at 22:48, Gert Doering wrote: > > On Wed, Jun 23, 2010 at 09:10:10AM +0200, Jan Just Keijser wrote: > > > assigns a 169.254 address. If this works for you as well then maybe the > > > tap-win32 developers can dive deeper into this and find out why windows > > > treats the 'always connected' adapter differently from an 'application > > > controlled' adapter . > > > > I'd assume that windows services are not "bound" to "dynamic" interfaces... > > By dynamic interface you mean an interface which has "Obtain IP address > automatically" set? No, I was thinking about interfaces that sort of "are not always there". But that was a misconception, the TAP interface *is* always there - what's application controlled is whether it's "connected to an ethernet cable" (virtual, of course) all the time, or only if openvpn tells it so. But in that my idea doesn't really make sense - it's as if windows wouldn't start windows sharing if the ethernet cable is not plugged in at boot time. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
[Openvpn-devel] How-To for OpenVPN on OpenWRT
Hi, as promised a few weeks ago at the IRC meeting, I've sat down and built an OpenVPN-devel package (based on ecrist's weekly tar balls, which in come from dazo's git tree). I've written this all down in the secure-computing wiki, and would welcome feedback on the content, and some help in fixing the wiki-fu to make it look more nice :-) http://secure-computing.net/wiki/index.php/OpenVPN/OpenWRT - have fun. (I still don't know how whether one can use the same tree to build multiple different architectures in parallel - but if one of you knows, please add to the wiki) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] How-To for OpenVPN on OpenWRT
Hi,
On Sun, Jun 27, 2010 at 05:13:35PM +0200, Gert Doering wrote:
> as promised a few weeks ago at the IRC meeting, I've sat down and built
> an OpenVPN-devel package (based on ecrist's weekly tar balls, which
> in come from dazo's git tree).
>
> I've written this all down in the secure-computing wiki, and would welcome
> feedback on the content, and some help in fixing the wiki-fu to make it
> look more nice :-)
>
> http://secure-computing.net/wiki/index.php/OpenVPN/OpenWRT
>
> - have fun.
Update: this is now also in the openvpn.net wiki:
https://community.openvpn.net/openvpn/wiki/OpenvpnDevelPackageForOpenWRT
and this is where I will maintain updates (as we have agreed in the
community IRC meeting last thursday).
The SCN wiki page is still there, I just added a pointer to the openvpn.net
wiki, and I will not maintain it any longer.
Feedback is still welcome, of course :-)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
[Openvpn-devel] Patch for compile-time problems on NetBSD and OpenBSD (trac #17)
Hi,
the following patch fixes the IFF_MULTICAST compile-time problems on NetBSD,
and it should also fix them on OpenBSD (trac entry #17).
** important: after applying the patch to configure.ac, you MUST run
** "autoreconf" - otherwise the patch won't do anything
If it still doesn't work for OpenBSD, I need to see the parts from your
config.log relating to
gert
-- snip ----
Signed-off-by: Gert Doering
---
configure.ac |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4626e46..b91a41c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -371,6 +371,9 @@ if test "${WIN32}" != "yes"; then
[#ifdef HAVE_SYS_SOCKET_H
# include
#endif
+ #ifdef HAVE_SYS_TYPES_H
+ # include
+ #endif
])
AC_CHECK_HEADERS(netinet/ip.h,,,
[#ifdef HAVE_SYS_TYPES_H
--
1.6.4.4
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] Patch for compile-time problems on NetBSD and OpenBSD (trac #17)
Hi,
On Fri, Jul 09, 2010 at 10:31:02AM +0200, Gert Doering wrote:
> the following patch fixes the IFF_MULTICAST compile-time problems on NetBSD,
> and it should also fix them on OpenBSD (trac entry #17).
This would have been too easy... on NetBSD, can be
include before (which the original patch does), on OpenBSD,
this fails.
So I have swapped around these two includes in the test program
compiled by configure, and it now configure and compiles both on NetBSD
and on OpenBSD just fine. (Last time I had no OpenBSD to test - in the
mean time, I've setup an OpenBSD 4.7 VM and tested it myself, so I'm *sure*
it works :-) ).
Due to the fact that I've commited this in two goes, it's "two patches"
now... I've appended both. Please apply to a clean configure.ac file,
and to be sure, run "autoreconf" to rebuild "configure" (to Matthias:
well, the magic might do this automatically, but before I get another
bug report "your patch did not help" which could then be due to
"autoreconf not run", I'll just make *sure* it was rebuilt).
"David needs an independent ACK on this, so please test on NetBSD and
OpenBSD and give feedback".
gert
--------
From bc1a247c42afe51b027cb02acfab7cb1c986ce88 Mon Sep 17 00:00:00 2001
From: Gert Doering
List-Post: openvpn-devel@lists.sourceforge.net
Date: Fri, 9 Jul 2010 10:24:46 +0200
Subject: [PATCH 1/2] Fix compile problems on NetBSD and OpenBSD - configure
will not find
due to missing in the test program, and thus,
tun.c will fail to compile with missing symbol IFF_MULTICAST.
Signed-off-by: Gert Doering
---
configure.ac |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4626e46..b91a41c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -371,6 +371,9 @@ if test "${WIN32}" != "yes"; then
[#ifdef HAVE_SYS_SOCKET_H
# include
#endif
+ #ifdef HAVE_SYS_TYPES_H
+ # include
+ #endif
])
AC_CHECK_HEADERS(netinet/ip.h,,,
[#ifdef HAVE_SYS_TYPES_H
--
1.7.0.5
From 38e455b18f468b72e0357d49b0284a9372c7d9b2 Mon Sep 17 00:00:00 2001
From: Gert Doering
List-Post: openvpn-devel@lists.sourceforge.net
Date: Sat, 10 Jul 2010 11:24:41 +0200
Subject: [PATCH 2/2] Fix compile time problems on OpenBSD for good -
previous fix
fixed NetBSD but not OpenBSD (include *after* )
Signed-off-by: Gert Doering
---
configure.ac |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index b91a41c..3fb08ba 100644
--- a/configure.ac
+++ b/configure.ac
@@ -368,12 +368,12 @@ if test "${WIN32}" != "yes"; then
linux/types.h sys/poll.h sys/epoll.h err.h dnl
)
AC_CHECK_HEADERS(net/if.h,,,
-[#ifdef HAVE_SYS_SOCKET_H
- # include
- #endif
- #ifdef HAVE_SYS_TYPES_H
+[#ifdef HAVE_SYS_TYPES_H
# include
#endif
+ #ifdef HAVE_SYS_SOCKET_H
+ # include
+ #endif
])
AC_CHECK_HEADERS(netinet/ip.h,,,
[#ifdef HAVE_SYS_TYPES_H
--
1.7.0.5
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
pgple2sVuhFu3.pgp
Description: PGP signature
Re: [Openvpn-devel] feat_ipv6_payload problems on Solaris 10
Hi,
On Sat, Jul 10, 2010 at 09:55:49PM +1200, Michal Ludvig wrote:
> I'm having a problem with feat_ipv6_payload branch (checked out from git
> yesterday). One end is Solaris 10 (sparc) and the other end is Linux.
Which version of the tun driver are you using for Solaris?
My test solaris machine (Solaris 10 on Sparc64, but not the very latest
version) uses the driver from http://www.whiteboard.ne.jp/~admin2/tuntap/
and IPv6 works fine there. The web page says that this driver did not
support IPv6 before 11/16/2009 - so maybe this is the problem.
I am not using point-to-point tun but point-to-multipoint tun, but from
your logs, ptp tun should work just fine - and I'm happy to see someone
test p2p tun mode :-). From the interface setup side of things, there
should not be a difference between "p2mp client on solaris" and "one
end of a p2p tun on solaris" anyway.
So - if you could make sure that you have the very latest tun driver,
and it still doesn't work, I'm happy to help you debug this, as it
really should work. These days I'm fairly busy so it might take
a few days, though. (Just as an advance warning if I don't answer
right away).
Oh: don't use the tun.c from the whiteboard web page - this is parallel
work, and it won't work with feat_ipv6_payload. Integration of
Kazuyoshi-san's tun.c work into openvpn-testing is on my TODO list :-)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
pgpo5NBI3dkaX.pgp
Description: PGP signature
Re: [Openvpn-devel] feat_ipv6_payload problems on Solaris 10
Hi, On Sun, Jul 11, 2010 at 12:08:31AM +1200, Michal Ludvig wrote: > >> I'm having a problem with feat_ipv6_payload branch (checked out from git > >> yesterday). One end is Solaris 10 (sparc) and the other end is Linux. > > Which version of the tun driver are you using for Solaris? > > > > My test solaris machine (Solaris 10 on Sparc64, but not the very latest > > version) uses the driver from http://www.whiteboard.ne.jp/~admin2/tuntap/ > > and IPv6 works fine there. The web page says that this driver did not > > support IPv6 before 11/16/2009 - so maybe this is the problem. > That was it! Works now: > > [Linux] ~ # ping6 -n 2001:cafe::1 > PING 2001:cafe::1(2001:cafe::1) 56 data bytes > 64 bytes from 2001:cafe::1: icmp_seq=343 ttl=255 time=54.3 ms > 64 bytes from 2001:cafe::1: icmp_seq=344 ttl=255 time=50.1 ms > ^C Cool :-) - congratulations! (And thanks for testing point-to-point tun mode - I assumed it would work, but it's still on my test-plan...) > I used to have CSWtun from Blastwave - it's labeled as version 1.1 as > well so I believed it was the right thing. Hmmm. I wasn't aware that that one exists - but it might be worth a try to send them a note that they might want to do some updates. > Is there any way to check that the right module is loaded at runtime? > That may help avoid some confusion in the future... Good questions. I don't know right now, but I'll try to find out. > (BTW is there any work in progress for a v6 transport?) Well, there's feat_ipv6_transport by jjo, and of course, the "allmerged" branch which has both v6 payload and v6 transport. As far as I understand, the v6 transport stuff works on all "major" platforms supported by OpenVPN and generally gets the job done :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
[Openvpn-devel] [PATCH] feat_ipv6_payload on OpenBSD
Hi, here's a patch on top of feat_ipv6_payload to make IPv6 payload work on OpenBSD. Tested on 4.7. I've pushed it to git://compile.srv01.mucip.net/openvpn-gert.git (master), so David can "just pull" it to the feat_ipv6_payload branch - but he asked me to send all changes to the mailing list as well to get review. Well, here you are :-) gert >From e1f41b55a294c4f70a72d02e77aca140ac10a3a3 Mon Sep 17 00:00:00 2001 From: Gert Doering List-Post: openvpn-devel@lists.sourceforge.net Date: Sun, 8 Aug 2010 12:34:00 +0200 Subject: [PATCH] implement IPv6 ifconfig + route setup/deletion on OpenBSD destroy tunX interface on tun_close() tested on OpenBSD 4.7 Signed-off-by: Gert Doering --- ChangeLog.IPv6 | 18 ++ route.c| 28 tun.c | 36 +--- 3 files changed, 71 insertions(+), 11 deletions(-) diff --git a/ChangeLog.IPv6 b/ChangeLog.IPv6 index 6fcfaa4..4275389 100644 --- a/ChangeLog.IPv6 +++ b/ChangeLog.IPv6 @@ -315,3 +315,21 @@ Sun Mar 7 19:17:33 CET 2010 is older than 9.7, log warning and disable IPv6 (won't work anyway). * release as patch 20100307-1 + +Sat Jul 10 14:37:52 CEST 2010 + + * TEST SUCCESS: point-to-point tun mode with --ifconfig-ipv6 between + Solaris10/sparc and Linux (Michal Ludvig) +(using the whiteboard tun driver on Solaris, otherwise "no IPv6") + +Sun Aug 8 12:30:44 CEST 2010 + + * route.c: split NetBSD and OpenBSD parts of add_route_ipv6() and + delete_route_ipv6(), implement OpenBSD variant + (needs "-prefixlen nn" while NetBSD uses "/nn") + + * tun.c: implement IPv6 ifconfig for OpenBSD + + * tun.c: destroy tunX interface at tun_close() on OpenBSD (cleanup) + + * TEST SUCCESS: OpenBSD 4.7: client-tun/net30, v4+v6 diff --git a/route.c b/route.c index 820a3a3..84d155d 100644 --- a/route.c +++ b/route.c @@ -1400,17 +1400,23 @@ add_route_ipv6 (struct route_ipv6 *r6, const struct tuntap *tt, unsigned int fla argv_msg (D_ROUTE, &argv); status = openvpn_execve_check (&argv, es, 0, "ERROR: MacOS X route add -inet6 command failed"); -#elif defined(TARGET_OPENBSD) || defined(TARGET_NETBSD) +#elif defined(TARGET_OPENBSD) - /* GERT-TODO: this needs real-world testing on OpenBSD, but it should work - */ + argv_printf (&argv, "%s add -inet6 %s -prefixlen %d %s", + ROUTE_PATH, + network, r6->netbits, gateway ); + + argv_msg (D_ROUTE, &argv); + status = openvpn_execve_check (&argv, es, 0, "ERROR: OpenBSD route add -inet6 command failed"); + +#elif defined(TARGET_NETBSD) argv_printf (&argv, "%s add -inet6 %s/%d %s", ROUTE_PATH, network, r6->netbits, gateway ); argv_msg (D_ROUTE, &argv); - status = openvpn_execve_check (&argv, es, 0, "ERROR: NetBSD/OpenBSD route add -inet6 command failed"); + status = openvpn_execve_check (&argv, es, 0, "ERROR: NetBSD route add -inet6 command failed"); #else msg (M_FATAL, "Sorry, but I don't know how to do 'route ipv6' commands on this operating system. Try putting your routes in a --route-up script"); @@ -1670,17 +1676,23 @@ delete_route_ipv6 (const struct route_ipv6 *r6, const struct tuntap *tt, unsigne argv_msg (D_ROUTE, &argv); openvpn_execve_check (&argv, es, 0, "ERROR: *BSD route delete -inet6 command failed"); -#elif defined(TARGET_OPENBSD) || defined(TARGET_NETBSD) +#elif defined(TARGET_OPENBSD) - /* GERT-TODO: this needs real-world testing on OpenBSD, but it should work - */ + argv_printf (&argv, "%s delete -inet6 %s -prefixlen %d %s", + ROUTE_PATH, + network, r6->netbits, gateway ); + + argv_msg (D_ROUTE, &argv); + openvpn_execve_check (&argv, es, 0, "ERROR: OpenBSD route delete -inet6 command failed"); + +#elif defined(TARGET_NETBSD) argv_printf (&argv, "%s delete -inet6 %s/%d %s", ROUTE_PATH, network, r6->netbits, gateway ); argv_msg (D_ROUTE, &argv); - openvpn_execve_check (&argv, es, 0, "ERROR: NetBSD/OpenBSD route delete -inet6 command failed"); + openvpn_execve_check (&argv, es, 0, "ERROR: NetBSD route delete -inet6 command failed"); #else msg (M_FATAL, "Sorry, but I don't know how to do 'route ipv6' commands on this operating system. Try putting your routes in a --route-down script"); diff --git a/tun.c b/tun.c index b038ce9..3e4b37f 100644 --- a/tun.c +++ b/tun.c @@ -572,7 +572,7 @@ init_tun_post (struct tuntap *tt, } #if defined(TARGET_WIN32) || \ -defined(TARGET_DARWIN) || defined(TARGET_NETBSD) +defined(TARGET_DARWIN) || defined(TARGET_NETBSD) || defined(TARGET_OPENBSD) /* som
[Openvpn-devel] RFD: VPN client test framework
Hi,
as discussed in one of the previous the IRC meetings, I've been working
on a test framework to enable full "fire up openvpn client, establish
VPN connection, run ping tests, clean up, verify cleanup" automated
tests.
The framework is appended below (as patch, should apply cleanly against
all branches in git) and has been checked & pushed into my feat_ipv6_payload
branch (dazo, feel free to pull & merge wherever you find this useful).
How does it work?
- you run "sudo make check" (needs root access to configure tun if!)
- t_client.sh reads t_client.rc from current dir or ${srcdir}
- t_client.rc defines a number of "test suffixes" to run (could be
"1" "2" "3" or "p2m", "p2p", "special" or whatever you like), and
for each suffix, there's config variables to specify
- how to call OpenVPN
- which hosts to ping for IPv4 and IPv6 when OpenVPN is up
(and actually before starting OpenVPN - to make the test more
meaningful, I have decided that the test hosts must not ping
before the tests starts)
- which addresses must show up in the output of "ifconfig" after
OpenVPN has started
- all variables except OPENVPN_CONF_ are optional
(this should all be fairly obvious from looking at t_client.rc-sample)
- the script wants to connect to a well-defined OpenVPN server that
will assign well-known IPv4 (and IPv6) addresses, have well-defined
pingable addresse, etc. - so you need to setup the test server before
the script is useful for you. (Whether you use certificates or
username/password is up to you, you could even mix and match - run
one test with certs, and one with user/pass against different target
ports... :-) )
[we *could* run a "reference server" somewhere and ship a sample
t_client.rc + cert so that users could use this right away, but I
do not currently have the resources to run such a public server]
- whatever the script does is logged to a newly created directory
below the current directory (openvpn output, ifconfig+route before
starting OpenVPN, while running it, after ending it)
- important: at least on NetBSD and OpenBSD, the script will print
one failure, because the tun0 interface created is not destroyed
after openvpn ends. For OpenBSD, I have changed close_tun() to
do so ("ifconfig tun0 destroy"), for NetBSD I have not yet changed
anything - but I strongly believe that the output of "ifconfig+route"
should be reverted to exactly how it looked like before OpenVPN
was started, so I consider this a bug in the NetBSD-specific bits
of OpenVPN (and will look into this).
- the test framework has been tested on Linux, NetBSD and OpenBSD.
It *should* work fine on FreeBSD and Solaris.
It works on MacOS X (but the output looks funny, because /bin/sh
does not implement "echo -e" - need to add configure trickery)
It will *not* work on Windows yet - I haven't looked into what's
needed to make it work (background processes and signals in mingw
bash?), maybe it's as easy as adding the necessary "ipconfig" and
"netsh" commands to print interface + routing config...
- I have only tested "connect via IPv4 transport, use IPv4+IPv6 payload",
but the framework is generic enough that "connect via IPv6 transport"
should work just fine (just setup OPENVPN_CONF_x accordingly in the
t_client.rc).
- this is neither finished nor pretty, but it helps me a *lot* in
quickly testing whether I broke anything when fiddling system-dependent
code (tun.c, route.c) across multiple build hosts - so I hope this
is going to be fairly useful to Samuli and the buildbot :-)
enjoy,
gert
>From a75f441b83cf07de2180b67f057c9d41ea2a447d Mon Sep 17 00:00:00 2001
From: Gert Doering
List-Post: openvpn-devel@lists.sourceforge.net
Date: Sun, 8 Aug 2010 21:24:30 +0200
Subject: [PATCH] full "VPN client connect" test framework for OpenVPN
run from "make check" if "t_client.rc" is found in workdir or srcdir
(copy t_client.rc-sample, fill in specifics for your test server)
Signed-off-by: Gert Doering
---
Makefile.am|2 +-
t_client.rc-sample | 83 +++
t_client.sh| 298
3 files changed, 382 insertions(+), 1 deletions(-)
create mode 100644 t_client.rc-sample
create mode 100755 t_client.sh
diff --git a/Makefile.am b/Makefile.am
index 7bccc11..73d9892 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -55,7 +55,7 @@ SUBDIRS = \
service-win32 \
install-win32
-TESTS = t_lpback.sh t_cltsrv.sh
+TESTS = t_client.sh t_lpback.sh t_cltsrv.sh
sbin_PROGRAMS = openvpn
dist_noinst_HEADERS = \
diff --git a/t_client.rc-sample b/t_client.rc-sam
Re: [Openvpn-devel] RFD: VPN client test framework
Hi,
On Sun, Aug 08, 2010 at 09:48:47PM +0200, Gert Doering wrote:
> as discussed in one of the previous the IRC meetings, I've been working
> on a test framework to enable full "fire up openvpn client, establish
> VPN connection, run ping tests, clean up, verify cleanup" automated
> tests.
I got some feedback from Waldner on IRC, and had to make it work on
Solaris (broken /bin/sh) - so this is now built using "configure",
knows how to find "ip", "ifconfig" and "netstat" (configure does the
work :-) ), *and* has been tested on Solaris (works!).
The patch goes on top of the previous one. Pushed to my git repo.
gert
From a91aef97487096595011a5d1716fe33fa654afe5 Mon Sep 17 00:00:00 2001
From: Gert Doering
List-Post: openvpn-devel@lists.sourceforge.net
Date: Tue, 10 Aug 2010 12:39:28 +0200
Subject: [PATCH] renamed t_client.sh to t_client.sh.in
build t_client.sh by configure at run-time, with proper paths to
ip/ifconfig/netstat binaries, and (most important) with proper #!SHELL
extend configure.ac to find "netstat" binary and to chmod +x "t_client.sh"
Signed-off-by: Gert Doering
---
configure.ac |8 ++
t_client.sh| 298
t_client.sh.in | 298
3 files changed, 306 insertions(+), 298 deletions(-)
delete mode 100755 t_client.sh
create mode 100755 t_client.sh.in
diff --git a/configure.ac b/configure.ac
index 116ff7c..a495f14 100644
--- a/configure.ac
+++ b/configure.ac
@@ -267,6 +267,13 @@ AC_ARG_WITH(route-path,
)
AC_DEFINE_UNQUOTED(ROUTE_PATH, "$ROUTE", [Path to route tool])
+AC_ARG_WITH(netstat-path,
+ [ --with-netstat-path=PATH Path to netstat tool],
+ [NETSTAT="$withval"],
+ [AC_PATH_PROG([NETSTAT], [netstat], [netstat],
[$PATH:/usr/local/sbin:/usr/sbin:/sbin:/etc])]
+)
+AC_DEFINE_UNQUOTED(NETSTAT_PATH, "$NETSTAT", [Path to netstat tool])
+
AC_ARG_WITH(mem-check,
[ --with-mem-check=TYPE Build with debug memory checking, TYPE = dmalloc
or valgrind],
[MEMCHECK="$withval"]
@@ -911,6 +918,7 @@ if test -z "${htmldir}"; then
fi
# end workaround
+AC_CONFIG_FILES([t_client.sh], [chmod +x t_client.sh])
AC_OUTPUT([
Makefile
openvpn.spec
diff --git a/t_client.sh b/t_client.sh
deleted file mode 100755
index 3a0dadb..000
--- a/t_client.sh
+++ /dev/null
@@ -1,298 +0,0 @@
-#!/bin/sh
-#
-# run OpenVPN client against ``test reference'' server
-# - check that ping, http, ... via tunnel works
-# - check that interface config / routes are properly cleaned after test end
-#
-# prerequisites:
-# - openvpn binary in current directory
-# - writable current directory to create subdir for logs
-# - t_client.rc in current directory OR source dir that specifies tests
-# - for "ping4" checks: fping binary in $PATH
-# - for "ping6" checks: fping6 binary in $PATH
-#
-
-if [ ! -x ./openvpn ]
-then
-echo "no (executable) openvpn binary in current directory. FAIL." >&2
-exit 1
-fi
-
-if [ ! -w . ]
-then
-echo "current directory is not writable (required for logging). FAIL." >&2
-exit 1
-fi
-
-if [ -r ./t_client.rc ] ; then
-. ./t_client.rc
-elif [ -r "${srcdir}"/t_client.rc ] ; then
-. "${srcdir}"/t_client.rc
-else
-echo "cannot find 't_client.rc' in current directory or" >&2
-echo "source dir ('${srcdir}'). FAIL." >&2
-exit 1
-fi
-
-if [ -z "$CA_CERT" ] ; then
-echo "CA_CERT not defined in 't_client.rc'. SKIP test." >&2
-exit 0
-fi
-
-if [ -z "$TEST_RUN_LIST" ] ; then
-echo "TEST_RUN_LIST empty, no tests defined. SKIP test." >&2
-exit 0
-fi
-
-# make sure we have permissions to run ifconfig/route from OpenVPN
-# can't use "id -u" here - doesn't work on Solaris
-ID=`id`
-if expr "$ID" : "uid=0" >/dev/null
-then :
-else
-echo "$0: this test must run be as root. SKIP." >&2
-exit 0
-fi
-
-LOGDIR=t_client-`hostname`-`date +%Y%m%d-%H%M%S`
-if mkdir $LOGDIR
-then :
-else
-echo "can't create log directory '$LOGDIR'. FAIL." >&2
-exit 1
-fi
-
-exit_code=0
-
-# --
-# helper functions
-# --
-# print failure message, increase FAIL counter
-fail()
-{
-echo ""
-echo "FAIL: $@" >&2
-fail_count=$(( $fail_count + 1 ))
-}
-
-# print "all interface IP addresses" + "all routes"
-# this is higly system dependent...
-get_ifconfig_route()
-{
-# linux / iproute2?
-if [ -x /sbin/ip -o -x /usr/sbin/ip ]
-
Re: [Openvpn-devel] [PATCH] Test framework improvment - Do not FAIL if t_client.rc is missing
Hi,
On Wed, Aug 18, 2010 at 02:27:31PM +0200, David Sommerseth wrote:
> This is to avoid 'make check' fail if this extra test case is not
> configured. The patch gives a PASS, but will notify the user that
> this test was skipped.
Ummm. Dunno what I have been smoking :-) ("if you don't want to
test this, this must be a mistake!!!") - but since this is not
something everyone will be using, your patch makes more sense.
ACK, and thanks.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH v2] Test framework improvment - Do not FAIL if t_client.rc is missing
Hi, On Wed, Aug 18, 2010 at 03:04:03PM +0200, David Sommerseth wrote: > This is to avoid 'make check' fail if this extra test case is not > configured. [..] > +exit 77 > +fi > + ACK again. Better :) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] Test framework improvment - Do not FAIL if t_client.rc is missing
Hi,
On Wed, Aug 18, 2010 at 02:36:57PM +0200, Matthias Andree wrote:
> Am 18.08.2010 14:27, schrieb David Sommerseth:
> > This is to avoid 'make check' fail if this extra test case is not
> > configured. The patch gives a PASS, but will notify the user that
> > this test was skipped.
>
> The other question is how t_client.rc can go missing...
It's not shipped by default. Since you need to setup a reference server,
and this cannot be the same machine (since you can't enforce that packets
go through the tun/tap then), it's not something that can be successfully
tested "just by extracting the tarball and run make ; make check".
We ship a t_client.rc-sample that explains what goes in there and how
to enable this.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH v2] Test framework improvment - Do not FAIL if t_client.rc is missing
Hi,
On Wed, Aug 18, 2010 at 03:27:45PM +0200, Matthias Andree wrote:
> > +if [ -r ./t_client.rc ] ; then
> > +. ./t_client.rc
> > +elif [ -r "${srcdir}"/t_client.rc ] ; then
> > +. "${srcdir}"/t_client.rc
> > +else
> > +echo "$0: cannot find 't_client.rc' in current directory or" >&2
> > +echo "$0: source dir ('${srcdir}'). SKIPPING TEST." >&2
> > +exit 77
> > +fi
>
> I have occasionally been bitten by such ambiguities between current working
> directory and $srcdir. I'd propose to steer clear of such precedence rules.
I'm using this on purpose here - I have a number of machines that build
using the same $srcdir (mounted over NFS), and one of them has no working
IPv6-over-tun. So this special machine has a t_client.rc in its
build directory which sources $srcdir/t_client.rc and subsequently
unsets all IPv6-related test targets.
So all machines can use the same generic t_client.rc, and if I need to
fiddle with things on individual hosts, I can do so, without having to
maintain a "nearly identical" copy on all machines.
> > if [ -z "$CA_CERT" ] ; then
> > echo "CA_CERT not defined in 't_client.rc'. SKIP test." >&2
> > exit 0
>
> I think you missed this "exit 0" - should also be 77 instead - and please
> check
> if there are more (I've not been looking at the source script for lack of
> time).
There are some more.
David, could you patch these as well? Otherwise I need to go cherrypicking
your changes first (and this might take longer).
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: [Openvpn-devel] [PATCH] More t_client.sh updates - exit with SKIP when we want to skip
Hi, On Wed, Aug 18, 2010 at 05:06:27PM +0200, David Sommerseth wrote: > Several places we exited with 0 instead of 77 when we want to indicate > that we should skip this test. ACK. Thanks to Matthias for pointing this out. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpVlgCvTiva5.pgp Description: PGP signature
Re: [Openvpn-devel] Summary of the IRC meeting (19th Aug 2010)
Hi,
On Fri, Aug 20, 2010 at 05:35:36PM +0200, Peter Stuge wrote:
> Samuli Seppänen wrote:
> > converting the OpenVPN build system (on Windows) to depend only on
> > python, Visual Studio Professional and DDK. The original build
> > system required bash and various other UNIX tools.
>
> James' mentioned argument for prefering Visual Studio, namely that
> MinGW may not have all the most recent functions in .h files, is not
> so good IMO. Since James also seems to prefer working outside Windows
> I would rather try to make OpenVPN for Windows crosscompileable, both
> driver and app.
The app is cross-compileable today - but to make that work requires that
all relevant Windows APIs are exported in mingw headers *and libraries*.
Windows APIs have the nasty habit of changing over time, so if mingw
stops updating their libraries etc., OpenVPN would be sort of stuck
to the old APIs - which might turn into a problem. Or might not. We
don't know...
> libusb-win32 can already compile their driver using MinGW.
To be able to cross-compile the driver would certainly be nice. Need to
check how libusb-win32 does this...
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
pgpJA0tfGiNHg.pgp
Description: PGP signature
Re: [Openvpn-devel] Summary of the IRC meeting (19th Aug 2010)
Hi, On Fri, Aug 20, 2010 at 10:56:51AM -0500, Karl O. Pinc wrote: > On 08/20/2010 10:48:17 AM, Gert Doering wrote: > > > The app is cross-compileable today - but to make that work requires > > that > > all relevant Windows APIs are exported in mingw headers *and > > libraries*. > > > > Windows APIs have the nasty habit of changing over time, so if mingw > > stops updating their libraries etc., OpenVPN would be sort of stuck > > to the old APIs - which might turn into a problem. Or might not. We > > don't know... > > You could also say that, for instance, > gcc might not keep up-to-date and it'd be better to use, say, > the Intel compiler which is faster anyway. Which C compiler to use doesn't really matter, as long as the C compiler (and the system libraries) presents all necessary APIs for this platform. > What makes mingw different from gcc? It is really in such danger? mingw has the same problem as WINE: it's following a foreign API that's beeing extended and changed regularily. It's not "the native platform environment", so they always have to play catch-up. Don't get me wrong, I'm a big fan of mingw - I'm just explaining why this could be a problem if, for example, Windows 8 needs a new way to configure IP addresses on a tap interface and the necessary API is just not there in the mingw environment. > I've had fewer problems with open source projects being > discontinued than I have had with proprietary products. Well, I've had my share of stale and unmaintained open source projects, and also of commercial pain. OTOH, the assumption that microsoft will continue to provide compiler environments for their OSes is not fully unwarranted :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpHRJeafV0IH.pgp Description: PGP signature
Re: [Openvpn-devel] Summary of the IRC meeting (19th Aug 2010)
Hi, On Fri, Aug 20, 2010 at 06:24:06PM +0200, Peter Stuge wrote: > Gert Doering wrote: > > The app is cross-compileable today - but to make that work requires that > > all relevant Windows APIs are exported in mingw headers *and libraries*. > > Sure. You emphasize libraries, but MinGW is not so much a library as > it is a wrapper for the standard runtime from MS. [..] > > so if mingw stops updating their libraries etc., OpenVPN would be > > sort of stuck to the old APIs - which might turn into a problem. > > Or might not. We don't know... > > What could happen is that OpenVPN wants to use a brand new API which > was introduced in e.g. Windows 7, and if MinGW doesn't yet support > this, then it can't be used. Yes, this was what I understood James to be worried about. > First of all, I'm not sure that will happen, since we want OpenVPN to > be backwards compatible for older Windows systems too. It might be necessary if "the API that we currently use" stops working on Win8 or so... (and yes, that would require different #ifdef branches for "old windows" and "new windows" - nasty, but sometimes unavoidable) > But if it really is neccessary, then maybe that API can be added to > MinGW with very little effort, since MinGW is just a wrapper. Now that's good news. I had the assumption that they are basically providing "re-engineered" versions of the windows libraries etc. (as WINE does for the runtime environment). That would have been much more work. > > > libusb-win32 can already compile their driver using MinGW. > > > > To be able to cross-compile the driver would certainly be nice. > > Need to check how libusb-win32 does this... > > They've switched to depending on the WDK (supercedes the DDK) out of > preference and stopped supporting MinGW builds. Rev 212 from May is > the last that cross-compiles without problems. > > svn co -r 212 > https://libusb-win32.svn.sourceforge.net/svnroot/libusb-win32/trunk/libusb > libusb-win32 > cd libusb-win32/ > make host_prefix=i686-mingw32 libusb0.sys > > (You may need another prefix.) Will check this out - not that I have any realy understanding how windows device driver building really works, but I've done "build tap with WDK" (because you can't download DDK any longer), so maybe it's enough to put the pieces togehter. thanks, gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpiZ6LsFKYM8.pgp Description: PGP signature
Re: [Openvpn-devel] [PATCH 3/3] Added a simple plug-in demonstrating the v3 plug-in API.
Hi,
On Thu, Aug 26, 2010 at 11:44:00PM +0200, David Sommerseth wrote:
> This plug-in can be tested by running an OpenVPN server like this:
>
> # ./openvpn --plugin plugin/examples/log_v3.so --dev tun \
> --server 192.168.240.0 255.255.255.0 --ca sample-keys/ca.crt \
> --cert sample-keys/server.crt --key sample-keys/server.key \
> --dh sample-keys/dh1024.pem
>
> The client can be started like this:
>
> # ./openvpn --client --remote localhost --ca sample-keys/ca.crt \
> --cert sample-keys/client.crt --key sample-keys/client.key \
> --dev tun --nobind --auth-user-pass
You might want to take a look at t_cltsrv.sh and build a "make check" test
script from there... verifying the expected output in the logfile after
the test run...
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
pgpA4Qq6JBUY9.pgp
Description: PGP signature
Re: [Openvpn-devel] Summary of the IRC meeting (26th Aug 2010)
Hi, On Sat, Aug 28, 2010 at 04:46:17AM +0200, Peter Stuge wrote: > Samuli Seppänen wrote: > > Discussed the "Some way of supporting static compilation" issue: > > > > <https://community.openvpn.net/openvpn/ticket/46> > > > > Did some testing to see if creating a static binary would be > > trivial. As it was not, > > Why wasn't it? Please share details from the testing. Naively just calling "gcc -static" led to linker failures due to OpenSSL not being found. This was a "can we do it that easily?" quick test, so we didn't investigate further why it failed. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp_R05toDvuF.pgp Description: PGP signature
Re: [Openvpn-devel] Netmask OpenVPN Server
Hi, On Tue, Aug 31, 2010 at 12:35:03PM +0200, Eike Lohmann wrote: > In the past only /16 networks were possibel per openvpn instance. > Is it now possibel to define larger networks or define 2x /16 networks > on one openvpn instance? I assume that you're talking about this error message: --server directive netmask allows for too many host addresses (subnet must be %s or higher) right? If yes, it should work to change #define IFCONFIG_POOL_MIN_NETBITS16 in pool.h to "14" (etc) and recompile - every extra bit will double memory consumption [for the pool handling, of I remember right], so use with care. (You really have more than 16000 users on a single OpenVPN instance? Wow, I'm impressed!) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp9HhXjZM4t5.pgp Description: PGP signature
