openvpn-devel Mailing List for OpenVPN

 Am 30.04.15 um 15:02 schrieb Gert Doering: > down-root.c was missing an #ifdef HAVE_ERR_H around <err.h> > (only relevant on AIX, it seems) > > Trac #495 > > Signed-off-by: Gert Doering <ge...@gr...> > --- > src/plugins/down-root/down-root.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/src/plugins/down-root/down-root.c b/src/plugins/down-root/down-root.c > index 6931bec..42db064 100644 > --- a/src/plugins/down-root/down-root.c > +++ b/src/plugins/down-root/down-root.c > @@ -42,7 +42,9 @@ > #include <signal.h> > #include <syslog.h> > #include <errno.h> > +#ifdef HAVE_ERR_H > #include <err.h> > +#endif > > #include <openvpn-plugin.h> > ACK. Arne 

Hi, On Thu, Apr 30, 2015 at 03:02:40PM +0200, Gert Doering wrote: > down-root.c was missing an #ifdef HAVE_ERR_H around <err.h> > (only relevant on AIX, it seems) Ignore that patch, please. While it makes the compile error go away, of course it will (sometimes... wtf?!) lead to a link error, as err() and warn() are not there either... New patch not using err()/warn() coming. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

down-root.c was missing an #ifdef HAVE_ERR_H around <err.h> (only relevant on AIX, it seems) Trac #495 Signed-off-by: Gert Doering <ge...@gr...> --- src/plugins/down-root/down-root.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/plugins/down-root/down-root.c b/src/plugins/down-root/down-root.c index 6931bec..42db064 100644 --- a/src/plugins/down-root/down-root.c +++ b/src/plugins/down-root/down-root.c @@ -42,7 +42,9 @@ #include <signal.h> #include <syslog.h> #include <errno.h> +#ifdef HAVE_ERR_H #include <err.h> +#endif #include <openvpn-plugin.h> -- 1.6.4 

Patch has been applied to the master and release/2.3 branch. commit 3a840739e43acc5ea15814be08debb9dbb7ba67c (master) commit 3a840739e43acc5ea15814be08debb9dbb7ba67c (release/2.3) Author: Gert Doering Date: Tue Apr 28 12:20:19 2015 +0200 explain effect of --topology subnet on --ifconfig Signed-off-by: Gert Doering <ge...@gr...> Acked-by: Steffan Karger <ste...@fo...> Message-Id: <143...@gr...> URL: http://article.gmane.org/gmane.network.openvpn.devel/9616 -- kind regards, Gert Doering 

On Wed, 2015-04-29 at 23:30 +0200, Gert Doering wrote: > Hi, > > On Wed, Apr 29, 2015 at 08:33:02PM -0000, David Woodhouse wrote: > > > That would mean we either go into autoconf territory to test for groff > > > run-time behaviour, or we use a particular unique sequence and do our > > > own post-processing. > > > > The latter is baaically the approach I took in > > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/5f51c83f2 > > So you put "−" in the .8 file, which is converted to "-" for > HTML - but what happens for "man openconnect"? Will groff understand > "−" and output a "proper U+002D HYPHEN-MINUS"? (Not that it's > particular fun to edit such .8 files then...) No, in the .8 file I left it as \- I then seem to get the desired U+002D output from man(1) in the terminal, and the patch referenced above is fixing up the − which we get in XHTML output, for the web rendition which is used at http://www.infradead.org/openconnect/manual.html Quite why we don't get U+2212 MINUS SIGN in the terminal output too, I don't know. That's just groff being inconsistent. > (There's a famous saying about "it would be much easier to teach them > all English" when it comes to internationalization, charsets, and all > that pain...) Seems rather naïve to assume that sticking solely to English would allow us to stick to ASCII. ∃ lots of reasons to use non-ASCII characters, even when you're sticking to English. ☺ -- dwmw2 

 On 28-04-15 12:20, Gert Doering wrote: > The fact that the second parameter of --ifconfig is no longer > a "remote address" but a "netmask" when using --dev tun and > --topology subnet was not documented clearly enough. > > Trac #370 > > Signed-off-by: Gert Doering <ge...@gr...> > --- > doc/openvpn.8 | 23 ++++++++++++++++++----- > 1 file changed, 18 insertions(+), 5 deletions(-) > > diff --git a/doc/openvpn.8 b/doc/openvpn.8 > index 8b3e1a2..587b769 100644 > --- a/doc/openvpn.8 > +++ b/doc/openvpn.8 > @@ -798,6 +798,12 @@ driver supports an > command which sets a subnet instead of a remote endpoint IP address. > > This option exists in OpenVPN 2.1 or higher. > + > +Note: Using > +.B \-\-topology subnet > +changes the interpretation of the arguments of > +.B \-\-ifconfig > +to mean "address netmask", no longer "local remote". > .\"********************************************************* > .TP > .B \-\-tun-ipv6 > @@ -861,16 +867,21 @@ May be used in order to execute OpenVPN in unprivileged environment. > Set TUN/TAP adapter parameters. > .B l > is the IP address of the local VPN endpoint. > -For TUN devices, > +For TUN devices in point-to-point mode, > .B rn > is the IP address of the remote VPN endpoint. > -For TAP devices, > +For TAP devices, or TUN devices used with > +.B \-\-topology subnet, > .B rn > -is the subnet mask of the virtual ethernet segment > +is the subnet mask of the virtual network segment > which is being created or connected to. > > For TUN devices, which facilitate virtual > -point-to-point IP connections, > +point-to-point IP connections (when used in > +.B \-\-topology net30 > +or > +.B p2p > +mode), > the proper usage of > .B \-\-ifconfig > is to use two private IP addresses > @@ -885,7 +896,9 @@ you will be pinging across the VPN. > > For TAP devices, which provide > the ability to create virtual > -ethernet segments, > +ethernet segments, or TUN devices in > +.B --topology subnet > +mode (which create virtual "multipoint networks"), > .B \-\-ifconfig > is used to set an IP address and > subnet mask just as a physical > ACK -Steffan 

Hi, On Wed, Apr 29, 2015 at 08:33:02PM -0000, David Woodhouse wrote: > > That would mean we either go into autoconf territory to test for groff > > run-time behaviour, or we use a particular unique sequence and do our > > own post-processing. > > The latter is baaically the approach I took in > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/5f15c83f2 So you put "−" in the .8 file, which is converted to "-" for HTML - but what happens for "man openconnect"? Will groff understand "−" and output a "proper U+002D HYPHEN-MINUS"? (Not that it's particular fun to edit such .8 files then...) (There's a famous saying about "it would be much easier to teach them all English" when it comes to internationalization, charsets, and all that pain...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

 > That would mean we either go into autoconf territory to test for groff > run-time behaviour, or we use a particular unique sequence and do our > own post-processing. The latter is baaically the approach I took in http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/5f15c83f2 -- dwmw2 

Am 29.04.2015 um 14:07 schrieb David Woodhouse: > On Tue, 2015-03-31 at 09:19 +0200, Matthias Andree wrote: >> I am concerned this will cause misformattings and inability to search >> for options with leading dashes on some systems - I don't recall >> versions, but I do know that some systems used some sort of Unicode >> (soft?) hyphen for a simple non-escaped MINUS character (ASCII 0x2B). > > cf. https://bugzilla.redhat.com/show_bug.cgi?id=1173619 > > I'm not sure there *is* a right answer. Groff will interpret a bare '- > ' as a hyphen, and may render it in output as U+2010 HYPHEN. It will > interpret an escaped '\-' as a minus sign, and may render it in output > as U+2212 MINUS SIGN. > > I'm not aware of any way to actually *tell* groff that we want the > output to be a U+002D HYPHEN-MINUS. Either way, we rely on undefined > behaviour of the output drivers which may vary from system to system. > > Basically, I think groff is just broken. There is a thread at > http://lists.gnu.org/archive/html/groff/2015-01/threads.html which > I've just discovered, but I'm not sure I can see a conclusion there > that I understand. That would mean we either go into autoconf territory to test for groff run-time behaviour, or we use a particular unique sequence and do our own post-processing. 

On Tue, 2015-03-31 at 09:19 +0200, Matthias Andree wrote: > I am concerned this will cause misformattings and inability to search > for options with leading dashes on some systems - I don't recall > versions, but I do know that some systems used some sort of Unicode > (soft?) hyphen for a simple non-escaped MINUS character (ASCII 0x2B). cf. https://bugzilla.redhat.com/show_bug.cgi?id=1173619 I'm not sure there *is* a right answer. Groff will interpret a bare '- ' as a hyphen, and may render it in output as U+2010 HYPHEN. It will interpret an escaped '\-' as a minus sign, and may render it in output as U+2212 MINUS SIGN. I'm not aware of any way to actually *tell* groff that we want the output to be a U+002D HYPHEN-MINUS. Either way, we rely on undefined behaviour of the output drivers which may vary from system to system. Basically, I think groff is just broken. There is a thread at http://lists.gnu.org/archive/html/groff/2015-01/threads.html which I've just discovered, but I'm not sure I can see a conclusion there that I understand. -- dwmw2 

 > Am 31.03.2015 um 08:44 schrieb sa...@op...: >> From: Samuli Seppänen <sa...@op...> >> >> This patch is against the release/2.3 branch >> >> Trac: 512 >> Signed-off-by: Samuli Seppänen <sa...@op...> >> --- >> doc/openvpn.8 | 1800 ++++++++++++++++++++++++++++----------------------------- >> 1 file changed, 900 insertions(+), 900 deletions(-) >> >> diff --git a/doc/openvpn.8 b/doc/openvpn.8 >> index a95d353..bcd2d76 100644 >> --- a/doc/openvpn.8 >> +++ b/doc/openvpn.8 >> @@ -37,7 +37,7 @@ >> .TH openvpn 8 "17 November 2008" >> .\"********************************************************* >> .SH NAME >> -openvpn \- secure IP tunnel daemon. >> +openvpn - secure IP tunnel daemon. > I am concerned this will cause misformattings and inability to search > for options with leading dashes on some systems - I don't recall > versions, but I do know that some systems used some sort of Unicode > (soft?) hyphen for a simple non-escaped MINUS character (ASCII 0x2B). > > So, for the release/2.3 branch, NAK for now, and more questions on the > 2.4/trunk. > > My objections will be void the moment that we can be sure that those > (major) distributions that played with the Unicode outside-ASCII hyphens > in *roff have gone out of support, and supported versions no longer > modify the plain ASCII minus, but render it verbatim. Matthias: I did additional research and it seems that escaping dashes in _options_ (but nowhere else) is the correct approach, see <https://community.openvpn.net/openvpn/ticket/512#comment:9> Any objections to this approach? -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Patch has been applied to the master and release/2.3 branches. commit 4ad2b65d9deb3197d847d7dcc36715aa5394836f (master) commit 1a7fc1ea2207580693b2801099f8a473f1c07828 (release/2.3) Author: Gert Doering Date: Tue Apr 28 13:04:23 2015 +0200 Print helpful error message on --mktun/--rmtun if not available. Signed-off-by: Gert Doering <ge...@gr...> Acked-by: David Sommerseth <da...@us...> Message-Id: <143...@gr...> URL: http://article.gmane.org/gmane.network.openvpn.devel/9617 -- kind regards, Gert Doering 

On 28/04/15 13:04, Gert Doering wrote: > OpenVPN only supports --mktun/--rmtun to create/destroy persistant > tunnels on Linux. On BSD OSes, "ifconfig tun0 create" can do the > same job, so we do not actually need to support it - but the previous > error message ("unknown option") wasn't helpful. So always accept > the option now, and on non-supported systems, direct user to manpage. > > Trac #85 > > Signed-off-by: Gert Doering <ge...@gr...> > --- > src/openvpn/init.c | 10 ++++++++-- > src/openvpn/options.c | 2 -- > 2 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/src/openvpn/init.c b/src/openvpn/init.c > index b97d2da..42cb3e2 100644 > --- a/src/openvpn/init.c > +++ b/src/openvpn/init.c > @@ -887,7 +887,6 @@ do_genkey (const struct options * options) > bool > do_persist_tuntap (const struct options *options) > { > -#ifdef ENABLE_FEATURE_TUN_PERSIST > if (options->persist_config) > { > /* sanity check on options for --mktun or --rmtun */ > @@ -901,14 +900,21 @@ do_persist_tuntap (const struct options *options) >	) >	msg (M_FATAL|M_OPTERR, > "options --mktun or --rmtun should only be used together with --dev"); > +#ifdef ENABLE_FEATURE_TUN_PERSIST > tuncfg (options->dev, options->dev_type, options->dev_node, > options->persist_mode, > options->username, options->groupname, &options->tuntap_options); > if (options->persist_mode && options->lladdr) > set_lladdr(options->dev, options->lladdr, NULL); > return true; > - } > +#else > + msg( M_FATAL|M_OPTERR, > +	"options --mktun and --rmtun are not available on your operating " > +	"system. Please check 'man tun' (or 'tap'), whether your system " > + "supports using 'ifconfig %s create' / 'destroy' to create/remove " > + "persistant tunnel interfaces.", options->dev ); > #endif > + } > return false; > } > > diff --git a/src/openvpn/options.c b/src/openvpn/options.c > index e8cf06a..4f27336 100644 > --- a/src/openvpn/options.c > +++ b/src/openvpn/options.c > @@ -7023,7 +7023,6 @@ add_option (struct options *options, > options->pkcs11_id_management = true; > } > #endif > -#ifdef ENABLE_FEATURE_TUN_PERSIST > else if (streq (p[0], "rmtun")) > { > VERIFY_PERMISSION (OPT_P_GENERAL); > @@ -7036,7 +7035,6 @@ add_option (struct options *options, > options->persist_config = true; > options->persist_mode = 1; > } > -#endif > else if (streq (p[0], "peer-id")) > { > VERIFY_PERMISSION (OPT_P_PEER_ID); > (Lets try again, this time to the mailing list) ACK. -- kind regards, David Sommerseth 

OpenVPN only supports --mktun/--rmtun to create/destroy persistant tunnels on Linux. On BSD OSes, "ifconfig tun0 create" can do the same job, so we do not actually need to support it - but the previous error message ("unknown option") wasn't helpful. So always accept the option now, and on non-supported systems, direct user to manpage. Trac #85 Signed-off-by: Gert Doering <ge...@gr...> --- src/openvpn/init.c | 10 ++++++++-- src/openvpn/options.c | 2 -- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/src/openvpn/init.c b/src/openvpn/init.c index b97d2da..42cb3e2 100644 --- a/src/openvpn/init.c +++ b/src/openvpn/init.c @@ -887,7 +887,6 @@ do_genkey (const struct options * options) bool do_persist_tuntap (const struct options *options) { -#ifdef ENABLE_FEATURE_TUN_PERSIST if (options->persist_config) { /* sanity check on options for --mktun or --rmtun */ @@ -901,14 +900,21 @@ do_persist_tuntap (const struct options *options)	)	msg (M_FATAL|M_OPTERR, "options --mktun or --rmtun should only be used together with --dev"); +#ifdef ENABLE_FEATURE_TUN_PERSIST tuncfg (options->dev, options->dev_type, options->dev_node, options->persist_mode, options->username, options->groupname, &options->tuntap_options); if (options->persist_mode && options->lladdr) set_lladdr(options->dev, options->lladdr, NULL); return true; - } +#else + msg( M_FATAL|M_OPTERR, +	"options --mktun and --rmtun are not available on your operating " +	"system. Please check 'man tun' (or 'tap'), whether your system " + "supports using 'ifconfig %s create' / 'destroy' to create/remove " + "persistant tunnel interfaces.", options->dev ); #endif + } return false; } diff --git a/src/openvpn/options.c b/src/openvpn/options.c index e8cf06a..4f27336 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -7023,7 +7023,6 @@ add_option (struct options *options, options->pkcs11_id_management = true; } #endif -#ifdef ENABLE_FEATURE_TUN_PERSIST else if (streq (p[0], "rmtun")) { VERIFY_PERMISSION (OPT_P_GENERAL); @@ -7036,7 +7035,6 @@ add_option (struct options *options, options->persist_config = true; options->persist_mode = 1; } -#endif else if (streq (p[0], "peer-id")) { VERIFY_PERMISSION (OPT_P_PEER_ID); -- 2.2.2 

The fact that the second parameter of --ifconfig is no longer a "remote address" but a "netmask" when using --dev tun and --topology subnet was not documented clearly enough. Trac #370 Signed-off-by: Gert Doering <ge...@gr...> --- doc/openvpn.8 | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/doc/openvpn.8 b/doc/openvpn.8 index 8b3e1a2..587b769 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -798,6 +798,12 @@ driver supports an command which sets a subnet instead of a remote endpoint IP address. This option exists in OpenVPN 2.1 or higher. + +Note: Using +.B \-\-topology subnet +changes the interpretation of the arguments of +.B \-\-ifconfig +to mean "address netmask", no longer "local remote". .\"********************************************************* .TP .B \-\-tun-ipv6 @@ -861,16 +867,21 @@ May be used in order to execute OpenVPN in unprivileged environment. Set TUN/TAP adapter parameters. .B l is the IP address of the local VPN endpoint. -For TUN devices, +For TUN devices in point-to-point mode, .B rn is the IP address of the remote VPN endpoint. -For TAP devices, +For TAP devices, or TUN devices used with +.B \-\-topology subnet, .B rn -is the subnet mask of the virtual ethernet segment +is the subnet mask of the virtual network segment which is being created or connected to. For TUN devices, which facilitate virtual -point-to-point IP connections, +point-to-point IP connections (when used in +.B \-\-topology net30 +or +.B p2p +mode), the proper usage of .B \-\-ifconfig is to use two private IP addresses @@ -885,7 +896,9 @@ you will be pinging across the VPN. For TAP devices, which provide the ability to create virtual -ethernet segments, +ethernet segments, or TUN devices in +.B --topology subnet +mode (which create virtual "multipoint networks"), .B \-\-ifconfig is used to set an IP address and subnet mask just as a physical -- 2.0.5 

Hi, On Mon, Apr 27, 2015 at 09:27:21PM +0200, Gert Doering wrote: > Previously, the code tried to find res_init(), and on some systems > got it wrong in configure, silently not-using res_init(), leading > to unexpected failures to re-init the resolver. ... for the record: tested on FreeBSD 9.1, Gentoo-something, AIX(!), OpenSolaris and MacOS X - and either it found and added the library fine, or discovered that it didn't need to do anything, but in any case, the resulting socket.o always referenced res_init() and linking worked. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Previously, the code tried to find res_init(), and on some systems got it wrong in configure, silently not-using res_init(), leading to unexpected failures to re-init the resolver. We know that all supported OSes (except Windows) have res_init(), so change the call to "#ifndef WIN32", and adjust configure.ac to just find the library to link (if any). With that, failures to find res_init() are no longer "hidden" but clearly visible at link time. AC_SEARCH_LIBS() bits inspired by CUPS' cups_network.m4 (GPLv2) Fix trac #523 Signed-off-by: Gert Doering <ge...@gr...> --- configure.ac | 11 +++++------ src/openvpn/socket.c | 2 +- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index 9132468..a495c0d 100644 --- a/configure.ac +++ b/configure.ac @@ -613,12 +613,6 @@ AC_SUBST([SOCKETS_LIBS]) old_LIBS="${LIBS}" LIBS="${LIBS} ${SOCKETS_LIBS}" AC_CHECK_FUNCS([sendmsg recvmsg inet_ntop inet_pton]) -AC_CHECK_FUNCS( -	[res_init], -	, -	, -	[[#include <resolv.h>]] -) # Windows use stdcall for winsock so we cannot auto detect these m4_define(	[SOCKET_FUNCS], @@ -646,6 +640,11 @@ else fi LIBS="${old_LIBS}" +# we assume res_init() always exist, but need to find out *where*... +AC_SEARCH_LIBS(__res_init, resolv bind, , + AC_SEARCH_LIBS(res_9_init, resolv bind, , +	AC_SEARCH_LIBS(res_init, resolv bind, , ))) + AC_ARG_VAR([TAP_CFLAGS], [C compiler flags for tap]) old_CFLAGS="${CFLAGS}" CFLAGS="${CFLAGS} ${TAP_CFLAGS}" diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c index afc1e60..13ed981 100644 --- a/src/openvpn/socket.c +++ b/src/openvpn/socket.c @@ -314,7 +314,7 @@ openvpn_getaddrinfo (unsigned int flags, ASSERT(res); -#if defined(HAVE_RES_INIT) +#ifndef WIN32 res_init (); #endif -- 2.0.5 

Hi, On Mon, Apr 27, 2015 at 04:28:57PM +0200, Steffan Karger wrote: > But keep the chdir to / at the place where deamon() was before, to preserve > the current behaviour wrt relative paths in the config. > > This should fix the issue reported in trac #480, without changing the > behaviour visible to the end user. > > Note that by moving the daemon() call to an earlier stage of the init > process, we no longer have to call platform_mlockall() again, or do a > pkcs11_forkFixup(). I think this is good, so both feature-ACK and code-ACK from me (after staring at the patch and the doxygen generated call graphs for nearly an hour... whee is this a twisty maze of passages, all alike...). The overamazing thing is that this actually makes the code *more easy* in a number of places :-) I'd still like to hear feedback from the reporter on #480 if it actually solves their issue (though I'm confident it does). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 27.04.2015 um 16:48 schrieb David Sommerseth: > Having this said, if you do builds on systems with a more modern > automake, I do want to encourage people to run 'make V=0' or use > ./configure --enable-silent-rules. This will ensure we can capture > compiler warnings far easier. For now I do consider this fine, as you > do this explicitly - a different behaviour should be expected when > using explicit options. > > When the oldest distro we need to support have a modern enough > automake, we should revisit this topic of making the 'silent rules' > the default behaviour - being consistent across all distros. The question is who needs what information. I see the dichotomy as follows: - - Whilst operating on known terrain, as a developer, you can often ignore compiler command-lines because you usually are acquainted with what you're doing (and if not, it's time for sleep, sport, or food). That's "make -sj10 V=0" ground. - - Whilst providing end-user builds, perhaps through automated package builders, you do want verbose information, in order to avoid round-trips for asking further questions. Some build frameworks trigger verbose builds automatically, other's don't. (And if you flip the switch for default behaviour, I expect to see other consumers/end users show up and complain.) HTH Matthias -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU+eM4ACgkQvmGDOQUufZXmeQCfZzULHSU1evIzOvFp+os7Fdro 7wMAoOzFI6g9h9tREL/RgNkWnsypiO6I =3HdT -----END PGP SIGNATURE----- 

Hi, On Mon, Apr 27, 2015 at 04:48:38PM +0200, David Sommerseth wrote: > Just tested a ./configure (used automake 1.13.4 on RHEL7) with > - --enable-silent-rules. That worked like a charm out-of-the-box > without any patching. David, thanks for testing and reporting. With this, I think we can let this thread end - people that want silent output can have it today, no patches needed. (I, for one, like seeing the actual compiler and especially linker statements, as they are often needed to understand failures...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/15 14:07, Gert Doering wrote: > Hi, > > On Wed, Apr 15, 2015 at 09:19:45AM +0200, Matthias Andree wrote: >> - it changes policy through the [yes] argument to >> AM_SILENT_RULES(). This flips the switch for the default without >> good reason, and that makes debugging harder - this is a policy >> decision, not mechanism. > > Indeed, this we don't want. > > Having "V=0" or "--enable-silent-rules" is fine for me, but > changing the defaults to hide even more detail is not (annoying > enough that recent autoconfs hide the detailed results from "make > test") Just tested a ./configure (used automake 1.13.4 on RHEL7) with - --enable-silent-rules. That worked like a charm out-of-the-box without any patching. I do understand people wanting less output when compiling (which has been a Linux kernel compile feature for a very long time too, and many other projects as well). And I don't think that we loose that much information building it this way. In fact we can actually more easily see compiler warnings - which I would say is a good thing. If you need the full compile command line, it is available using 'V=1'. But I don't think we should make this behaviour the default yet, and at least not if that require dependencies to specific automake versions, especially when we know that RHEL5 (the oldest supported distro) runs a far older automake. I think it is best if the default behaviour is consistent across all distributions. Having this said, if you do builds on systems with a more modern automake, I do want to encourage people to run 'make V=0' or use ./configure --enable-silent-rules. This will ensure we can capture compiler warnings far easier. For now I do consider this fine, as you do this explicitly - a different behaviour should be expected when using explicit options. When the oldest distro we need to support have a modern enough automake, we should revisit this topic of making the 'silent rules' the default behaviour - being consistent across all distros. - -- kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU+TEYACgkQDC186MBRfroooACgrl7YapqCtq4NbtNAGRogEHpn 2zUAnRnyLDgDVMYzXF5DCXEy/ds583yL =QNhv -----END PGP SIGNATURE----- 

But keep the chdir to / at the place where deamon() was before, to preserve the current behaviour wrt relative paths in the config. This should fix the issue reported in trac #480, without changing the behaviour visible to the end user. Note that by moving the daemon() call to an earlier stage of the init process, we no longer have to call platform_mlockall() again, or do a pkcs11_forkFixup(). Signed-off-by: Steffan Karger <st...@ka...> --- src/openvpn/init.c | 32 +++++++++++--------------------- src/openvpn/init.h | 2 ++ src/openvpn/openvpn.c | 4 ++++ src/openvpn/pkcs11.c | 5 ----- src/openvpn/pkcs11.h | 3 --- 5 files changed, 17 insertions(+), 29 deletions(-) diff --git a/src/openvpn/init.c b/src/openvpn/init.c index 73c6aff..5b22c38 100644 --- a/src/openvpn/init.c +++ b/src/openvpn/init.c @@ -916,23 +916,20 @@ do_persist_tuntap (const struct options *options) * Should we become a daemon? * Return true if we did it. */ -static bool +bool possibly_become_daemon (const struct options *options) { bool ret = false; if (options->daemon) { ASSERT (!options->inetd); - if (daemon (options->cd_dir != NULL, options->log) < 0) + /* Don't chdir immediately, but the end of the init sequence, if needed */ + if (daemon (1, options->log) < 0)	msg (M_ERR, "daemon() failed or unsupported"); restore_signal_state (); if (options->log)	set_std_files_to_null (true); -#if defined(ENABLE_PKCS11) - pkcs11_forkFixup (); -#endif - ret = true; } return ret; @@ -1809,15 +1806,11 @@ do_deferred_options (struct context *c, const unsigned int found) * Possible hold on initialization */ static bool -do_hold (struct context *c) +do_hold (void) { #ifdef ENABLE_MANAGEMENT if (management) { - /* if c is defined, daemonize before hold */ - if (c && c->options.daemon && management_should_daemonize (management)) -	do_init_first_time (c); - /* block until management hold is released */ if (management_hold (management))	return true; @@ -1867,7 +1860,7 @@ socket_restart_pause (struct context *c) c->persist.restart_sleep_seconds = 0; /* do managment hold on context restart, i.e. second, third, fourth, etc. initialization */ - if (do_hold (NULL)) + if (do_hold ()) sec = 0; if (sec) @@ -1886,7 +1879,7 @@ do_startup_pause (struct context *c) if (!c->first_time) socket_restart_pause (c); else - do_hold (NULL); /* do management hold on first context initialization */ + do_hold (); /* do management hold on first context initialization */ } /* @@ -2743,7 +2736,7 @@ do_compute_occ_strings (struct context *c) static void do_init_first_time (struct context *c) { - if (c->first_time && !c->did_we_daemonize && !c->c0) + if (c->first_time && !c->c0) { struct context_0 *c0; @@ -2758,12 +2751,9 @@ do_init_first_time (struct context *c) /* get --writepid file descriptor */ get_pid_file (c->options.writepid, &c0->pid_state); - /* become a daemon if --daemon */ - c->did_we_daemonize = possibly_become_daemon (&c->options); - - /* should we disable paging? */ - if (c->options.mlock && c->did_we_daemonize) -	platform_mlockall (true);	/* call again in case we daemonized */ + /* perform postponed chdir if --daemon */ + if (c->did_we_daemonize && c->options.cd_dir == NULL) +	platform_chdir("/"); /* save process ID in a file */ write_pid (&c0->pid_state); @@ -3221,7 +3211,7 @@ open_management (struct context *c) } /* initial management hold, called early, before first context initialization */ - do_hold (c); + do_hold (); if (IS_SIG (c)) { msg (M_WARN, "Signal received from management interface, exiting"); diff --git a/src/openvpn/init.h b/src/openvpn/init.h index 5a1d1dc..d1908ed 100644 --- a/src/openvpn/init.h +++ b/src/openvpn/init.h @@ -55,6 +55,8 @@ bool do_genkey (const struct options *options); bool do_persist_tuntap (const struct options *options); +bool possibly_become_daemon (const struct options *options); + void pre_setup (const struct options *options); void init_instance_handle_signals (struct context *c, const struct env_set *env, const unsigned int flags); diff --git a/src/openvpn/openvpn.c b/src/openvpn/openvpn.c index fd87fc1..2f327f3 100644 --- a/src/openvpn/openvpn.c +++ b/src/openvpn/openvpn.c @@ -229,6 +229,10 @@ openvpn_main (int argc, char *argv[]) if (do_test_crypto (&c.options)) break; + /* become a daemon if --daemon */ + if (c.first_time) + c.did_we_daemonize = possibly_become_daemon (&c.options); + #ifdef ENABLE_MANAGEMENT /* open management subsystem */ if (!open_management (&c)) diff --git a/src/openvpn/pkcs11.c b/src/openvpn/pkcs11.c index 3a15ef6..a1f13c5 100644 --- a/src/openvpn/pkcs11.c +++ b/src/openvpn/pkcs11.c @@ -336,11 +336,6 @@ pkcs11_terminate () {	); } -void -pkcs11_forkFixup () { -	pkcs11h_forkFixup (); -} - bool pkcs11_addProvider (	const char * const provider, diff --git a/src/openvpn/pkcs11.h b/src/openvpn/pkcs11.h index 4261871..b49401c 100644 --- a/src/openvpn/pkcs11.h +++ b/src/openvpn/pkcs11.h @@ -38,9 +38,6 @@ pkcs11_initialize ( void pkcs11_terminate (); -void -pkcs11_forkFixup (); - bool pkcs11_addProvider (	const char * const provider, -- 2.1.4 

Hi, Unlike claimed earlier[1] we won't have an IRC meeting today. We will have a meeting next Monday, though: <https://community.openvpn.net/openvpn/wiki/Topics-2015-05-04> As can be seen, the agenda is still pretty empty, so feel free to suggest new topics. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock [1] <http://thread.gmane.org/gmane.network.openvpn.devel/9586/focus=9587> 

As described in trac #484, the current inline file size limit of 10000 bytes is becoming an issue for some users. Since RSA keys and signature sizes are increasing, we need to adjust our limits. As #484 reports, 10000 can be too small for PKCS#12 files with 4K RSA keys. Instead of postponing this issue by increasing the static limit, dynamically increase the buffer size while reading. This keeps the memory usage limited but does allow for larger inlined files. Signed-off-by: Steffan Karger <st...@ka...> --- src/openvpn/options.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/openvpn/options.c b/src/openvpn/options.c index e8cf06a..3195c5a 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -3698,12 +3698,21 @@ static char * read_inline_file (struct in_src *is, const char *close_tag, struct gc_arena *gc) { char line[OPTION_LINE_SIZE]; - struct buffer buf = alloc_buf (10000); + struct buffer buf = alloc_buf (8*OPTION_LINE_SIZE); char *ret; while (in_src_get (is, line, sizeof (line))) { if (!strncmp (line, close_tag, strlen (close_tag)))	break; + if (!buf_safe (&buf, strlen(line))) +	{ + /* Increase buffer size */ + struct buffer buf2 = alloc_buf (buf.capacity * 2); + ASSERT (buf_copy (&buf2, &buf)); + buf_clear (&buf); + free_buf (&buf); + buf = buf2; +	} buf_printf (&buf, "%s", line); } ret = string_alloc (BSTR (&buf), gc); -- 2.1.0 

For "topology subnet", we only pretend to have a subnet and keep using the tun if in point-to-point mode - but for that to fully work, the "remote" address needs to be different from the "local" address. So just arbitrarily construct one from the on-link subnet - base+1, if "that is not us", base+2, otherwise. Fix trac #481 Signed-off-by: Gert Doering <ge...@gr...> --- src/openvpn/tun.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index 11a6d71..aa7a9f0 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -626,6 +626,28 @@ void delete_route_connected_v6_net(struct tuntap * tt, } #endif +#if defined(TARGET_FREEBSD)||defined(TARGET_DRAGONFLY) +/* we can't use true subnet mode on tun on all platforms, as that + * conflicts with IPv6 (wants to use ND then, which we don't do), + * but the OSes want "a remote address that is different from ours" + * - so we construct one, normally the first in the subnet, but if + * this is the same as ours, use the second one. + * The actual address does not matter at all, as the tun interface + * is still point to point and no layer 2 resolution is done... + */ + +char * +create_arbitrary_remote( struct tuntap *tt, struct gc_arena * gc ) +{ + in_addr_t remote; + + remote = (tt->local & tt->remote_netmask) +1; + + if ( remote == tt->local ) remote ++; + + return print_in_addr_t (remote, 0, &gc); +} +#endif /* execute the ifconfig command through the shell */ void @@ -1150,7 +1172,7 @@ do_ifconfig (struct tuntap *tt, IFCONFIG_PATH, actual, ifconfig_local, - ifconfig_local, + create_arbitrary_remote( tt, &gc ), tun_mtu, ifconfig_remote_netmask ); -- 2.2.2