Re: [Openvpn-devel] combined ndis5 + ndis6 installer ?

[Samuli Seppänen]

Il 02/12/2016 05:54, Илья Шипицин ha scritto:
> unicode nsis is different from ansi nsis. for example, nsProcess needs
> different dll.

Ok. More research is needed to see what is involved, then.

> and, unicode nsis is not shipped in most common Linux repo (you need to
> install it separately).

Indeed, that was my impression. So far I've only seen NSIS 2.46 or so in 
the distribution repositories, and the link I provided talked about NSIS 
3.0b or something.

> taking the above into account, I think, I should repack the above
> packages as "makensis3" instead of "makensis".

You mean creating deb/rpm packages for updated NSIS? I think manually 
installing updated NSIS would be good enough, if repackaging proves to 
be too much of an effort.

>
> @mattock, which linux distro do you use for release building ?

Right now Ubuntu 14.04, but I should upgrade to 16.04 soon.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] combined ndis5 + ndis6 installer ?

[Илья Шипицин]

2016-12-01 16:40 GMT+05:00 Samuli Seppänen :

> Hi,
>
> Il 30/11/2016 11:58, Илья Шипицин ha scritto:
>
>>
>>
>> (and, yes, I'm going to build multi-language installer, probably
>> right
>> after 2.4 release)
>>
>>
>> This makes sense. Any plans on how you're going to do it?
>>
>>
>>
>> as we do not support windows 2000 anymore, we can easily switch to
>> unicode.
>> there are few questions
>>
>> 1) unicode nsis under linux (we use windows+mingw+nsis unicode, so, I'm
>> not sure about linux)
>>
>>
> Unicode seems to be present in Linux NSIS versions, according to this:
>
> 
>
> The build computers need to be updated to a quite recent NSIS version,
> though.
>


unicode nsis is different from ansi nsis. for example, nsProcess needs
different dll.
and, unicode nsis is not shipped in most common Linux repo (you need to
install it separately).

taking the above into account, I think, I should repack the above packages
as "makensis3" instead of "makensis".

@mattock, which linux distro do you use for release building ?



>
>
> 2) split installer into several language files (as done for openvpn-gui)
>>
>
> We'd also need to detect the language the user is using to select the
> correct one. I personally don't like manual language selector as they add
> one more step to the install process.
>
>
>> 3) test everything
>>
>>
>> it is not difficult, but it is time consuming, I'm afraid we will test
>> it properly before 2.4
>>
>
> The plan is to release 2.5 pretty quickly after 2.4. Also, installer
> changes do not necessarily need to go in sync with OpenVPN releases.
>
>
>> Another internationalization aspect we could improve is how we store
>> translations for OpenVPN-GUI. Editing the resource files directly is
>> clumsy and error-prone, as the files contain lots of "stuff" that is
>> not meant to be translated. A simple key-value file would be much
>> easier, although in OpenVPN-GUI's case the hardcoded window sizes
>> make this more complex.
>>
>>
>> it makes sense to convert openvpn-gui resources into visual studio format.
>> @selvanair some times ago told something like that.
>>
>
> Hmm, interesting, will need to look into it. Any format that could be
> loaded by a translation memory application is better than what we have now.
> Simple key-value resource files are also easy to convert into other similar
> formats, if necessary.
>
> as for the rest, separate resources are just fine.
>>
>>
>>
>> Also I'm not sure how easy it would be to separate the translatable
>> strings into a separate file. I would guess that the actual .res
>> files could be generated on the fly from a template and the
>> key-value file by the build scripts.
>>
>>
>> it looks overcomplicated. some kind of "post build operation" which will
>> identifies missing language resources would be nice however
>>
>
> Yeah, it could be hairy. Let's look into this in depth later.
>
>
> --
> Samuli Seppänen
> Community Manager
> OpenVPN Technologies, Inc
>
> irc freenode net: mattock
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] fuzz testing by google ?

[Илья Шипицин]

Hello,

https://opensource.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html

Cheers,
Ilya Shipitsin
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 2/2] Refuse to daemonize when running from systemd

[debbie10t]

Gutted ..

I have to step in here NOW and say that this did not work for me.

I applied to the current (as of this email) git master:

* Use systemd service manager notification
* The patch below
* No others.

-

then
$ autoreconf -ivf
$ ./configure --enable-systemd
$ make
# make uninstall
# make install

I then used the systemd unit from
b/src/distro/systemd/openvpn-server@.service
copied and renamed to my conf file as
/etc/systemd/system/openvpn-server@east.service

systemctl'd to the correct unit file:

# ls -l /etc/systemd/system/multi-user.target.wants
total ..
lrwxrwxrwx 1 root root 47 Dec  1 15:56 openvpn-server@east.service -> 
/etc/systemd/system/openvpn-server@east.service


changed the unit file as below:


# cat /etc/systemd/system/openvpn-server@east.service
[Unit]
Description=OpenVPN service for %I
After=syslog.target network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
RuntimeDirectory=openvpn-server
RuntimeDirectoryMode=0710
WorkingDirectory=/etc/openvpn/server

# Not using 2.3.x
#ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log 
--status-version 2 --suppress-timestamps --config %i.conf
# Do not like --supress-timestamps
#ExecStart=/usr/local/sbin/openvpn --status 
%t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps 
--config %i.conf
# Using this
ExecStart=/usr/local/sbin/openvpn --status 
%t/openvpn-server/status-%i.log --status-version 2 --config %i.conf
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw

[Install]
WantedBy=multi-user.target

My east.conf file:

# cat server/east.conf

### TESTS
#
## systemd enhancements: failed as expect
;bad-opt

## daemon: Did *not* fail when run from systemd service
daemon vpn-srv-east

  server 10.25.25.0 255.255.255.248
  server-ipv6 12fc:1918::10:25:25:0:0/112

push "setenv-safe PUSH_east arch"

keepalive 10 30
push "comp-lzo no"
   comp-lzo no
push "explicit-exit-notify 3"
client-config-dir /etc/openvpn/server/east/ccd
ccd-exclusive

log /etc/openvpn/server/east/temp/east.log
verb 4

management 127.0.0.1 10025
dev tun25s
port 10025
cipher AES-256-CBC
auth RSA-SHA512

# cert/key stuff
...


Then:
# systemctl daemon-reload
# systemctl start openvpn-server@east

** Openvpn started but should have failed **


Just for the hell of it

# nano b/src/openvpn/init.c

/*
  * Should we become a daemon?
  * Return true if we did it.
  */
bool
possibly_become_daemon (const struct options *options)
{
   bool ret = false;

#ifdef ENABLE_SYSTEMD
   /* return without forking if we are running from systemd */
   if (sd_notify(0, "READY=0") > 0)
 return ret;
#endif

   if (options->daemon)
 {
   ASSERT (!options->inetd);
   /* 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)
 [ line 921/4014 (22%), col 1/3 (33%), 
char 22889/106307 (21%) ]

-

I have probably done something wrong but could not sleep without letting 
someone know!

Regards




On 01/12/16 21:31, Christian Hesse wrote:
> From: Christian Hesse 
>
> We start with systemd Type=notify, so refuse to daemonize. This does not
> affect starting openvpn from script or command line.
>
> v2: Update commit message about script and command line.
>
> Signed-off-by: Christian Hesse 
> ---
>  distro/systemd/openvpn-client@.service | 1 -
>  distro/systemd/openvpn-server@.service | 1 -
>  src/openvpn/init.c | 7 +++
>  3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/distro/systemd/openvpn-client@.service 
> b/distro/systemd/openvpn-client@.service
> index f64a239..5618af3 100644
> --- a/distro/systemd/openvpn-client@.service
> +++ b/distro/systemd/openvpn-client@.service
> @@ -12,7 +12,6 @@ PrivateTmp=true
>  RuntimeDirectory=openvpn-client
>  RuntimeDirectoryMode=0710
>  WorkingDirectory=/etc/openvpn/client
> -ExecStartPre=/bin/sh -c 'grep -q -E ^daemon %i.conf || exit 0 && 
> /usr/bin/echo "OpenVPN configuration cannot contain --daemon when being 
> managed by systemd" ; exit 1'
>  ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf
>  CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID 
> CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
>  LimitNPROC=10
> diff --git a/distro/systemd/openvpn-server@.service 
> b/distro/systemd/openvpn-server@.service
> index 890e6a9..b9b4dba 100644
> --- a/distro/systemd/openvpn-server@.service
> +++ 

Re: [Openvpn-devel] [PATCH applied] Refuse to daemonize when running from systemd

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

ACK.  A natural continuation of commit c5931897ae8d663e7e.

Your patch has been applied to the master branch

commit 7660bba111f739f9cc7017c392c1434f201b8c44
Author: Christian Hesse
Date:   Thu Dec 1 22:31:04 2016 +0100

 Refuse to daemonize when running from systemd

 Signed-off-by: Christian Hesse 
 Tested-By: Richard Bonhomme 
 Acked-by: David Sommerseth 
 Message-Id: <20161201213104.5667-2-l...@eworm.de>
 URL: 
http://www.mail-archive.com/search?l=mid=20161201213104.5667-2-l...@eworm.de
 Signed-off-by: David Sommerseth 


- --
kind regards,

David Sommerseth

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJYQLJIAAoJEIbPlEyWcf3yMKgQAJapsRNhfkI1+WSaRP2PoVh/
scQQxFEV8HPHOASDtFZQZnaz3ZqkQ0yA+Zyn5w+KRefEIKGJ7/B8AWV5MfmtqPXS
d4TTbUXMziK+E4cJpcZukWm/r5eEjIfy6ZhNe+fopq3zMt/JtbJD9nbBjVOe+KiK
Kml60oUEP/vDmHKqQYJr69Z+9zgPC9W+etDY6MW6fyoo5O93G+OSenAeG2PJa3IZ
JsHOlcaYNIjrUKMZoxeiGKgqaU7aoTqHq/5l83cy7mayI8w3F6tOhYaH02NhVn15
PZ8BDJAG9Dl67/ROll9HO1HaoUegcpAR3lEXWAeRV7TaEn5x9W9HrmDJiWcuWZhj
BbvlqMmC0ocQyODul+6NFXWPX9+BmiReDGh+R6g+7H/ZhC01c4kyqBF+xne0DkSY
YnEs5ZMkxyY3ItrnUrQGiywayvDIsa0+DNv7jTRnVRy8bfnkKW0grOzDFQvyKqWR
K0rwBVOuKNqeRh6vhFSYNjfMIfcvkONMZKPlLjjHHIWzYr8eapxff6Ozw36UVXfI
1AGQ0bSChAjwufD9y6Xy+LDf+GtQI4kWkRjjjnXP/n01fYSLBJSGnLBWC3V+JUV1
JPT4GtD5cPAjxU3alGyrUMw4f18zXoqvlP82Kt+ViMneRwJkffxpOFWG7tD5MKYb
73a0O3IBgkb+SZRjFB4J
=xSqP
-END PGP SIGNATURE-

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Use systemd service manager notification

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

ACK.  Code looks good and does what it promises.  This also
improved the situation where OpenVPN needs username/passwords
from the console.  So this is indeed a far better solution.

The patch got also fairly good testing on a relatively short
time, across multiple systemd based distributions, client and
server profiles, even some configurations with explicit errors.

Your patch has been applied to the master branch

commit c5931897ae8d663e7e6244764fc6379d7b4740f3
Author: Christian Hesse
Date:   Thu Dec 1 22:31:03 2016 +0100

 Use systemd service manager notification

 Signed-off-by: Christian Hesse 
 Tested-By: Richard Bonhomme 
 Acked-by: David Sommerseth 
 Message-Id: <20161201213104.5667-1-l...@eworm.de>
 URL: 
http://www.mail-archive.com/search?l=mid=20161201213104.5667-1-l...@eworm.de
 Signed-off-by: David Sommerseth 


- --
kind regards,

David Sommerseth

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJYQLHEAAoJEIbPlEyWcf3y/gUQAJwqRYi5s0QcMyBhsdY3gRVd
kzU+OXiDXZtO/QgMN45rWpdZxAkp2IUxe3tFDEdQjzPsdcCRWL41l9dZcIxAuNEb
MHsv33/QUsH90svWGdhVH/nTf2ySR0rS3rLCuBCrwDfdm3mC7kQN7wsjaSRGcUIC
AdL5eAbDzrIntDJKXtN+m78lgpZ9zng2w2FHsizJcD2zLsjjSJgJNSO4fIyXs0D8
GZ/W1Ex1d4eMficWHKH6CYmj0dX0c6010X5lVdmT/d25TofahQBPReha0ej3jpAo
5dHtel4nGw+m5ooBa7tOnC5bWp8K7RAr8Vau6+sMhy9LabNZ5BY5Z0cBi/p0ViXx
hzlVFBCiVuXtEZhz9yHEp/uNbvnUNBfqzauyFmz7Obyyog3HWx7p5IM8LC7CNZF8
sL3wdSzxp7JFQrKl5vQb1MRAmmQZc/+DClLOxtdxX7bj3nc2wiP6C1iLoe+BvEZA
9tJIyfkh7oxM2Ec0Lt1yC7zMh+rknC5H6MffuvaapG7Xmc5iGekRJzWDZgZPtoJB
wreksV4OYUhFRogMMCCKHzfuCuIf3alLOocExNjUFHnAFJwFw+hq0r9YABbWtZ+c
FcePeavHusz0afAqyiAmEuQo6dxWN6Nq+lgDWV9SKrulRX0k7DB3/PgE2OfY3UEL
WaF1Gx2wZ0ur3SRZIrRA
=Y46U
-END PGP SIGNATURE-

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: Do not restart dns client service as a part of --register-dns processing

[Selva Nair]

Hi,

On Thu, Dec 1, 2016 at 3:21 AM, Gert Doering  wrote:

> ACK, thanks.
>
> Code looks good, and test compiles.  Have not test-run yet but do not
> expect any surprises there.
>
> I have added a Changes.rst entry (someone *might* notice and wonder if
> this was intentional :) ) and updated doc/openvpn.8 and the help text
> in options.c which both used to list all the commands run...
>
> Your patch has been applied to the master branch.
>

Do we want this in 2.3.14 as well ? If so I'll send a patch with service
part removed (note to self: remember to include docs and Changes.rst edits)

Selva
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v3 1/2] Use systemd service manager notification

[Christian Hesse]

From: Christian Hesse 

Notify systemd service manager when our initialization sequence
completed. This helps ordering services as dependencies can rely on vpn
being available.

v2: Add curly brackets (and indention) to block the else-part, msg()
call was non-conditional before.

v3: Move systemd header include from init.h to init.c.

Signed-off-by: Christian Hesse 
---
 distro/systemd/openvpn-client@.service |  1 +
 distro/systemd/openvpn-server@.service |  1 +
 src/openvpn/init.c | 14 +-
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/distro/systemd/openvpn-client@.service 
b/distro/systemd/openvpn-client@.service
index 18b84dd..f64a239 100644
--- a/distro/systemd/openvpn-client@.service
+++ b/distro/systemd/openvpn-client@.service
@@ -7,6 +7,7 @@ 
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
 Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO
 
 [Service]
+Type=notify
 PrivateTmp=true
 RuntimeDirectory=openvpn-client
 RuntimeDirectoryMode=0710
diff --git a/distro/systemd/openvpn-server@.service 
b/distro/systemd/openvpn-server@.service
index a2b7b52..890e6a9 100644
--- a/distro/systemd/openvpn-server@.service
+++ b/distro/systemd/openvpn-server@.service
@@ -7,6 +7,7 @@ 
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
 Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO
 
 [Service]
+Type=notify
 PrivateTmp=true
 RuntimeDirectory=openvpn-server
 RuntimeDirectoryMode=0710
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 2ccbab2..f99c934 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -30,6 +30,10 @@
 
 #include "syshead.h"
 
+#ifdef ENABLE_SYSTEMD
+#include 
+#endif
+
 #include "win32.h"
 #include "init.h"
 #include "sig.h"
@@ -1251,11 +1255,19 @@ initialization_sequence_completed (struct context *c, 
const unsigned int flags)
   show_adapters (M_INFO|M_NOPREFIX);
   msg (M_INFO, "%s With Errors ( see 
http://openvpn.net/faq.html#dhcpclientserv )", message);
 #else
+#ifdef ENABLE_SYSTEMD
+  sd_notifyf(0, "STATUS=Failed to start up: %s With Errors\nERRNO=1", 
message);
+#endif /* HAVE_SYSTEMD_SD_DAEMON_H */
   msg (M_INFO, "%s With Errors", message);
 #endif
 }
   else
-msg (M_INFO, "%s", message);
+{
+#ifdef ENABLE_SYSTEMD
+  sd_notifyf(0, "READY=1\nSTATUS=%s\nMAINPID=%lu", message, (unsigned 
long) getpid());
+#endif
+  msg (M_INFO, "%s", message);
+}
 
   /* Flag that we initialized */
   if ((flags & (ISC_ERRORS|ISC_SERVER)) == 0)
-- 
2.10.2


--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2 2/2] Refuse to daemonize when running from systemd

[Christian Hesse]

From: Christian Hesse 

We start with systemd Type=notify, so refuse to daemonize. This does not
affect starting openvpn from script or command line.

v2: Update commit message about script and command line.

Signed-off-by: Christian Hesse 
---
 distro/systemd/openvpn-client@.service | 1 -
 distro/systemd/openvpn-server@.service | 1 -
 src/openvpn/init.c | 7 +++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/distro/systemd/openvpn-client@.service 
b/distro/systemd/openvpn-client@.service
index f64a239..5618af3 100644
--- a/distro/systemd/openvpn-client@.service
+++ b/distro/systemd/openvpn-client@.service
@@ -12,7 +12,6 @@ PrivateTmp=true
 RuntimeDirectory=openvpn-client
 RuntimeDirectoryMode=0710
 WorkingDirectory=/etc/openvpn/client
-ExecStartPre=/bin/sh -c 'grep -q -E ^daemon %i.conf || exit 0 && /usr/bin/echo 
"OpenVPN configuration cannot contain --daemon when being managed by systemd" ; 
exit 1'
 ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf
 CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID 
CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
 LimitNPROC=10
diff --git a/distro/systemd/openvpn-server@.service 
b/distro/systemd/openvpn-server@.service
index 890e6a9..b9b4dba 100644
--- a/distro/systemd/openvpn-server@.service
+++ b/distro/systemd/openvpn-server@.service
@@ -12,7 +12,6 @@ PrivateTmp=true
 RuntimeDirectory=openvpn-server
 RuntimeDirectoryMode=0710
 WorkingDirectory=/etc/openvpn/server
-ExecStartPre=/bin/sh -c 'grep -q -E ^daemon %i.conf || exit 0 && /usr/bin/echo 
"OpenVPN configuration cannot contain --daemon when being managed by systemd" ; 
exit 1'
 ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log 
--status-version 2 --suppress-timestamps --config %i.conf
 CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
 LimitNPROC=10
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index f99c934..74f1139 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -930,6 +930,13 @@ bool
 possibly_become_daemon (const struct options *options)
 {
   bool ret = false;
+
+#ifdef ENABLE_SYSTEMD
+  /* return without forking if we are running from systemd */
+  if (sd_notify(0, "READY=0") > 0)
+return ret;
+#endif
+
   if (options->daemon)
 {
   ASSERT (!options->inetd);
-- 
2.10.2


--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 1/1] update year in copyright for README

[David Sommerseth]

On 01/12/16 18:39, Gert Doering wrote:
> Hi,
> 
> On Thu, Dec 01, 2016 at 05:43:28PM +0100, Christian Hesse wrote:
>> From: Christian Hesse 
>>
>> This line has not been touched in a long time... Let's
>> update the copyright with recent year for README.
> 
> I'm fine with merging these, but... could you send a combined 
> copyright-date-updating patch for *all* occurances, please?
> 
> Each patch that is merged is a few minutes work which should be
> spent thoughtfully :-)

I suggest we take a quick evaluation of updating the copyrights in all
files when we're doing the re-indenting task.  Whether we blend the
copyright update into the patches doing re-indenting, or as a separate
patch ... that's a different discussion (which we can agree upon on a
developers meeting or just on the #openvpn-devel channel whenever).


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc




signature.asc
Description: OpenPGP digital signature
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 1/1] update year in copyright for README

[Selva Nair]

Hi,

On Thu, Dec 1, 2016 at 12:39 PM, Gert Doering  wrote:

> On Thu, Dec 01, 2016 at 05:43:28PM +0100, Christian Hesse wrote:
> > From: Christian Hesse 
> >
> > This line has not been touched in a long time... Let's
> > update the copyright with recent year for README.
>
> I'm fine with merging these, but... could you send a combined
> copyright-date-updating patch for *all* occurances, please?
>
> Each patch that is merged is a few minutes work which should be
> spent thoughtfully :-)
>

IANL, but looks like the year update is just for "optics". Technically the
first year of publication should be enough, isn't it? Anyway updating
Copyright 2002-2010 to 2002-2016 would mean some changes where made in 2016
which is true for README, but tedious to figure out for each and every
file.

A simpler approach would be to update it only COPYING and let people who do
substantial edits to a file update copyright at that time if they feel the
urge...

Selva
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 1/1] update year in copyright for README

[Gert Doering]

Hi,

On Thu, Dec 01, 2016 at 05:43:28PM +0100, Christian Hesse wrote:
> From: Christian Hesse 
> 
> This line has not been touched in a long time... Let's
> update the copyright with recent year for README.

I'm fine with merging these, but... could you send a combined 
copyright-date-updating patch for *all* occurances, please?

Each patch that is merged is a few minutes work which should be
spent thoughtfully :-)

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


signature.asc
Description: PGP signature
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH 1/1] update year in copyright for README

[Christian Hesse]

From: Christian Hesse 

This line has not been touched in a long time... Let's
update the copyright with recent year for README.

Signed-off-by: Christian Hesse 
---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index 103a75a..6d2e9f3 100644
--- a/README
+++ b/README
@@ -1,6 +1,6 @@
 OpenVPN -- A Secure tunneling daemon
 
-Copyright (C) 2002-2010 OpenVPN Technologies, Inc. This program is free 
software;
+Copyright (C) 2002-2016 OpenVPN Technologies, Inc. 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.
-- 
2.10.2


--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: Force 'def1' method when --redirect-gateway is done through service

[Gert Doering]

Hi,

On Thu, Dec 01, 2016 at 11:19:56AM -0500, Selva Nair wrote:
> Did I overlook something?

Sounds too complex to me :-) - "just use def1" is good.

> Not that I like it. Wonder how android does it.

Well, there's a VPN API - you tell the API "these networks is what I want
to connect to" and then it will do routing table / routing policy magic
to get *your* packets into the tun (and nobody else's) - and on close
of the API, that stuff gets removed again.

Which is in a way similar to "def1" :-) - except that openvpn doesn't
have to do any cleanup (as far as I'm aware) and doesn't need to bother
about redirecting the existing gateway (install host route) and anything
because the API takes care of 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


signature.asc
Description: PGP signature
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: Force 'def1' method when --redirect-gateway is done through service

[Selva Nair]

Hi,

On Thu, Dec 1, 2016 at 3:07 AM, Gert Doering  wrote:

> On Wed, Nov 30, 2016 at 11:06:02PM +0100, Arne Schwabe wrote:
> > Slight correction. We actually set 0.0.0.0/0 on Android but Android
> > *always* translates that into a 0.0.0.0/1 and a 128.0.0.0/1 rule.
> >
> > We could do the same and do the translation in the interactive service
> > instead of OpenVPN itself.
>
> We could, but that wouldn't solve the issue of OpenVPN trying to
> remove the existing default route (which we would have to special-case-and-
> ignore) and reinstall it later on (which must not be translated to
> 2x /1, but ignored as well).
>
> The service code doesn't know whether a route is "for the VPN API" or
> "for anything else" (which openvpn on "non VPN API" platforms always
> could do) so this would be a much more intrusive change...


I think it could work like this:

In DeleteRoute()
   if dest == 0/0 delete routes to 0/1 and 128/1
   (ignore any "route does not exist" error)

In AddRoute() <-- this function doesn't currently exist
   if dest == 0/0 add routes to 0/1 and 128/1
   (this will add two extra routes when default gateway is restored, but
cant hurt)

In this scenario, route to 0/0 is never touched by the service.

When we ask the service to:
   delete default route to gw --> nothing happens unless there were routes
to 0/1 and 128/1
   add default route through tun  --> adds routes to 0/1 and 128/1 via tun
   delete default route through tun --> OK
   add default route to gw --> adds routes to 0/1 and 128/1 via gw

When process exits/crashes, the service thread exits and the extra routes
to 0/1 and 128/1 get removed. If service crashes those routes will remain,
not ideal, but safe, I suppose.

Did I overlook something?

Not that I like it. Wonder how android does it.

Selva
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2 2/2] Refuse to daemonize when running from systemd

[Christian Hesse]

From: Christian Hesse 

We start with systemd Type=notify, so refuse to daemonize. This does not
affect starting openvpn from script or command line.

Signed-off-by: Christian Hesse 
---
 distro/systemd/openvpn-client@.service | 1 -
 distro/systemd/openvpn-server@.service | 1 -
 src/openvpn/init.c | 7 +++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/distro/systemd/openvpn-client@.service 
b/distro/systemd/openvpn-client@.service
index f64a239..5618af3 100644
--- a/distro/systemd/openvpn-client@.service
+++ b/distro/systemd/openvpn-client@.service
@@ -12,7 +12,6 @@ PrivateTmp=true
 RuntimeDirectory=openvpn-client
 RuntimeDirectoryMode=0710
 WorkingDirectory=/etc/openvpn/client
-ExecStartPre=/bin/sh -c 'grep -q -E ^daemon %i.conf || exit 0 && /usr/bin/echo 
"OpenVPN configuration cannot contain --daemon when being managed by systemd" ; 
exit 1'
 ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf
 CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID 
CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
 LimitNPROC=10
diff --git a/distro/systemd/openvpn-server@.service 
b/distro/systemd/openvpn-server@.service
index 890e6a9..b9b4dba 100644
--- a/distro/systemd/openvpn-server@.service
+++ b/distro/systemd/openvpn-server@.service
@@ -12,7 +12,6 @@ PrivateTmp=true
 RuntimeDirectory=openvpn-server
 RuntimeDirectoryMode=0710
 WorkingDirectory=/etc/openvpn/server
-ExecStartPre=/bin/sh -c 'grep -q -E ^daemon %i.conf || exit 0 && /usr/bin/echo 
"OpenVPN configuration cannot contain --daemon when being managed by systemd" ; 
exit 1'
 ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log 
--status-version 2 --suppress-timestamps --config %i.conf
 CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
 LimitNPROC=10
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index aea3590..63a5fee 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -926,6 +926,13 @@ bool
 possibly_become_daemon (const struct options *options)
 {
   bool ret = false;
+
+#ifdef ENABLE_SYSTEMD
+  /* return without forking if we are running from systemd */
+  if (sd_notify(0, "READY=0") > 0)
+return ret;
+#endif
+
   if (options->daemon)
 {
   ASSERT (!options->inetd);
-- 
2.10.2


--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2 1/2] Use systemd service manager notification

[Christian Hesse]

From: Christian Hesse 

Notify systemd service manager when our initialization sequence
completed. This helps ordering services as dependencies can rely on vpn
being available.

Signed-off-by: Christian Hesse 
---
 distro/systemd/openvpn-client@.service |  1 +
 distro/systemd/openvpn-server@.service |  1 +
 src/openvpn/init.c | 10 +-
 src/openvpn/init.h |  4 
 4 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/distro/systemd/openvpn-client@.service 
b/distro/systemd/openvpn-client@.service
index 18b84dd..f64a239 100644
--- a/distro/systemd/openvpn-client@.service
+++ b/distro/systemd/openvpn-client@.service
@@ -7,6 +7,7 @@ 
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
 Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO
 
 [Service]
+Type=notify
 PrivateTmp=true
 RuntimeDirectory=openvpn-client
 RuntimeDirectoryMode=0710
diff --git a/distro/systemd/openvpn-server@.service 
b/distro/systemd/openvpn-server@.service
index a2b7b52..890e6a9 100644
--- a/distro/systemd/openvpn-server@.service
+++ b/distro/systemd/openvpn-server@.service
@@ -7,6 +7,7 @@ 
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
 Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO
 
 [Service]
+Type=notify
 PrivateTmp=true
 RuntimeDirectory=openvpn-server
 RuntimeDirectoryMode=0710
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 2ccbab2..aea3590 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1251,11 +1251,19 @@ initialization_sequence_completed (struct context *c, 
const unsigned int flags)
   show_adapters (M_INFO|M_NOPREFIX);
   msg (M_INFO, "%s With Errors ( see 
http://openvpn.net/faq.html#dhcpclientserv )", message);
 #else
+#ifdef ENABLE_SYSTEMD
+  sd_notifyf(0, "STATUS=Failed to start up: %s With Errors\nERRNO=1", 
message);
+#endif /* HAVE_SYSTEMD_SD_DAEMON_H */
   msg (M_INFO, "%s With Errors", message);
 #endif
 }
   else
-msg (M_INFO, "%s", message);
+{
+#ifdef ENABLE_SYSTEMD
+  sd_notifyf(0, "READY=1\nSTATUS=%s\nMAINPID=%lu", message, (unsigned 
long) getpid());
+#endif
+  msg (M_INFO, "%s", message);
+}
 
   /* Flag that we initialized */
   if ((flags & (ISC_ERRORS|ISC_SERVER)) == 0)
diff --git a/src/openvpn/init.h b/src/openvpn/init.h
index 524bc64..0518b06 100644
--- a/src/openvpn/init.h
+++ b/src/openvpn/init.h
@@ -27,6 +27,10 @@
 
 #include "openvpn.h"
 
+#ifdef ENABLE_SYSTEMD
+#include 
+#endif
+
 /*
  * Baseline maximum number of events
  * to wait for.
-- 
2.10.2


--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Mention that OpenVPN 2.4 requires Windows Vista or higher

[Gert Doering]

ACK. Your patch has been applied to the master branch.

commit 1c587a11122206186098c2014d407d0eb469656e
Author: Samuli Seppänen
Date:   Thu Dec 1 16:03:05 2016 +0200

 Mention that OpenVPN 2.4 requires Windows Vista or higher

 Signed-off-by: Samuli Seppänen 
 Acked-by: Gert Doering 
 Message-Id: <1480600985-25074-1-git-send-email-sam...@openvpn.net>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13357.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] push: Provide a warning if --ifconfig-push have argument mismatch with --topology

[Arne Schwabe]

Am 01.12.16 um 13:37 schrieb Gert Doering:
> Hi,
>
> On Thu, Dec 01, 2016 at 01:31:31PM +0100, Arne Schwabe wrote:
>> Am 30.11.16 um 23:41 schrieb David Sommerseth:
>>> This adds a warning to the log file if --topology is configured to use
>>> subnet or net30 and the 'subnet mask' argument of an --ifconfig-push option
>>> is not an subnet mask.  The check done is to ensure the first octet is 0xff 
>>> (255)
>> But way you actually want to test is
>>
>> if topology == subnet or net30:
>>if gateway not in net(ip, mask):
>>   print ("Your gw and ip and netmask disagree!)
>>
>> right? And isn't there code that gets executed for the client side that
>> can be disabled by ifconfig-nowarn. Can we reuse that code?
> That is certainly something we should test as well, but the particular
> case I had in mind was
>
>  - someone uses --topology p2p
>  - they have ccd/ files with "ifconfig-push 10.4.0.14 10.4.0.13"
>(for some clients that need to get a static address)
>  - they change their server.conf to --topology subnet
>  - everything works for "dynamic clients", but the static client now
>receives "10.4.0.13" and interprets it as a "netmask", which will
>cause the most interesting things, depending on platform code
>
> so the idea was to help this case by looking at only the "netmask" thing,
> and see if it makes sense (simplified sense: starts with 255.) - and if
> not, log this on the server side right when reading the ccd/ file so
> the admin in question can see "oh, I overlooked *that* special client".
>
> (Since that happened to a friend of mine based on my advice, I know that
> this is not a purely theoretical possibility :-) )
>

You are still very likely to catch this case If you check if in
net30/subnet the netmask is indead valid (e.g. CIDR)

Arne

--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] push: Provide a warning if --ifconfig-push have argument mismatch with --topology

[Steffan Karger]

On 01-12-16 13:38, Gert Doering wrote:
> On Thu, Dec 01, 2016 at 01:35:49PM +0100, Steffan Karger wrote:
>> On 1 December 2016 at 13:33, Gert Doering  wrote:
>>>((uchar *)>c2.push_ifconfig_remote_netmask)[0]
>>
>> Looks like dereferencing a type-punned pointer to me ;)
> 
> I was waiting for this :-)
> 
> (...but I thought "char *" is allowed by the rules?)

Heh, and I was worried that you had already though of this, so I must
have been wrong ;)

Indeed, "character types" (including unsigned char) are exempt of the
strict aliasing rules.  C99 6.5:

An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:
— [...], or
— a character type.

Apologies for the noise.

-Steffan



signature.asc
Description: OpenPGP digital signature
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 1/1] Use systemd service manager notification

[Christian Hesse]

Christian Hesse  on Wed, 2016/11/30 09:12:
> Ok, lets go into detail. We can use three different settings: Type=simple,
> Type=forking and Type=notify.
> 
> * We used Type=forking for a long time. That is fine: systemd reports
> success when the process forks off first time. That is when openvpn
> successfully completed initialization sequence.
> 
> * The current systemd unit use Type=simple (which is implicit). systemd
>   reports success as soon as the process is executed, it does not wait for
>   anything. So startup can look like that: systemd starts openvpn process ->
>   unit is in state 'started' -> openvpn bails out with an error
>   before the initialization sequence completed -> systemd unit is in state
>   'failed' now. The problem is that it was in state 'started'
> intermittently: Manual systemctl (starting service from command line)
> reports success, other services depending on openvpn are started while
> dependency failed later, ... This is just broken.
> 
> * My patch introduces Type=notify. The (main) process must not fork, so most
>   things work like simple, except that systemd does not report success on
>   process execution, but waits for the sd_notify() call. We do not have
>   intermittent state 'success' and everything works as expected.
> 
> I will not package the code as-is with our Arch Linux package. Either I
> revert back to Type=forking or apply the patch for Type=notify.
> 
> So I still vote to apply this as soon as possible.

I prepared an example:

root@leda ~ # systemctl start openvpn-client@lugor
root@leda ~ # systemctl status openvpn-client@lugor
● openvpn-client@lugor.service - OpenVPN tunnel for lugor
   Loaded: loaded (/usr/lib/systemd/system/openvpn-client@.service; enabled; 
vendor preset: disabled)
   Active: active (running) since Thu 2016-12-01 13:35:12 CET; 8s ago
 Docs: man:openvpn(8)
   https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
   https://community.openvpn.net/openvpn/wiki/HOWTO
  Process: 11700 ExecStartPre=/bin/sh -c grep -q -E ^daemon %i.conf || exit 0 
&& /usr/bin/echo "OpenVPN configuration cannot contain --daemon when being 
managed by systemd" ; exit 1 (code=exited, status=0/SUCCESS)
 Main PID: 11703 (openvpn)
Tasks: 1 (limit: 4915)
   CGroup: 
/system.slice/system-openvpn\x2dclient.slice/openvpn-client@lugor.service
   └─11703 /usr/sbin/openvpn --suppress-timestamps --nobind --config 
lugor.conf


Dec 01 13:35:13 leda openvpn[11703]: GID set to nobody
Dec 01 13:35:13 leda openvpn[11703]: UID set to nobody
Dec 01 13:35:13 leda openvpn[11703]: Initialization Sequence Completed
root@leda ~ # # looks good...
root@leda ~ # echo "bad-option" >> /etc/openvpn/client/lugor.conf
root@leda ~ # systemctl restart openvpn-client@lugor
root@leda ~ # # succeeds, no?
root@leda ~ # systemctl status openvpn-client@lugor
● openvpn-client@lugor.service - OpenVPN tunnel for lugor
   Loaded: loaded (/usr/lib/systemd/system/openvpn-client@.service; enabled; 
vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2016-12-01 13:36:14 CET; 15s ago
 Docs: man:openvpn(8)
   https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
   https://community.openvpn.net/openvpn/wiki/HOWTO
  Process: 11911 ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind 
--config %i.conf (code=exited, status=1/FAILURE)
  Process: 11908 ExecStartPre=/bin/sh -c grep -q -E ^daemon %i.conf || exit 0 
&& /usr/bin/echo "OpenVPN configuration cannot contain --daemon when being 
managed by systemd" ; exit 1 (code=exited, status=0/SUCCESS)
 Main PID: 11911 (code=exited, status=1/FAILURE)

Dec 01 13:36:14 leda systemd[1]: Starting OpenVPN tunnel for lugor...
Dec 01 13:36:14 leda systemd[1]: Started OpenVPN tunnel for lugor.
Dec 01 13:36:14 leda openvpn[11911]: Options error: Unrecognized option or 
missing or extra parameter(s) in lugor.conf:32: bad-option (2.4_beta2)
Dec 01 13:36:14 leda openvpn[11911]: Use --help for more information.
Dec 01 13:36:14 leda systemd[1]: openvpn-client@lugor.service: Main process 
exited, code=exited, status=1/FAILURE
Dec 01 13:36:14 leda systemd[1]: openvpn-client@lugor.service: Unit entered 
failed state.
Dec 01 13:36:14 leda systemd[1]: openvpn-client@lugor.service: Failed with 
result 'exit-code'.
3 root@leda ~ # # Oops...
3 root@leda ~ # # now install openvpn with my systemd patches
3 root@leda ~ # systemctl restart openvpn-client@lugor
Job for openvpn-client@lugor.service failed because the control process exited 
with error code.
See "systemctl status openvpn-client@lugor.service" and "journalctl -xe" for 
details.
1 root@leda ~ # systemctl status openvpn-client@lugor
● openvpn-client@lugor.service - OpenVPN tunnel for lugor
   Loaded: loaded (/usr/lib/systemd/system/openvpn-client@.service; enabled; 
vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2016-12-01 13:37:10 CET; 50s ago
 Docs: man:openvpn(8)
   

Re: [Openvpn-devel] [PATCH] push: Provide a warning if --ifconfig-push have argument mismatch with --topology

[Gert Doering]

Hi,

On Thu, Dec 01, 2016 at 01:35:49PM +0100, Steffan Karger wrote:
> On 1 December 2016 at 13:33, Gert Doering  wrote:
> >((uchar *)>c2.push_ifconfig_remote_netmask)[0]
> 
> Looks like dereferencing a type-punned pointer to me ;)

I was waiting for this :-)

(...but I thought "char *" is allowed by the rules?)

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


signature.asc
Description: PGP signature
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] push: Provide a warning if --ifconfig-push have argument mismatch with --topology

[Gert Doering]

Hi,

On Thu, Dec 01, 2016 at 01:31:31PM +0100, Arne Schwabe wrote:
> Am 30.11.16 um 23:41 schrieb David Sommerseth:
> > This adds a warning to the log file if --topology is configured to use
> > subnet or net30 and the 'subnet mask' argument of an --ifconfig-push option
> > is not an subnet mask.  The check done is to ensure the first octet is 0xff 
> > (255)
>
> But way you actually want to test is
> 
> if topology == subnet or net30:
>if gateway not in net(ip, mask):
>   print ("Your gw and ip and netmask disagree!)
> 
> right? And isn't there code that gets executed for the client side that
> can be disabled by ifconfig-nowarn. Can we reuse that code?

That is certainly something we should test as well, but the particular
case I had in mind was

 - someone uses --topology p2p
 - they have ccd/ files with "ifconfig-push 10.4.0.14 10.4.0.13"
   (for some clients that need to get a static address)
 - they change their server.conf to --topology subnet
 - everything works for "dynamic clients", but the static client now
   receives "10.4.0.13" and interprets it as a "netmask", which will
   cause the most interesting things, depending on platform code

so the idea was to help this case by looking at only the "netmask" thing,
and see if it makes sense (simplified sense: starts with 255.) - and if
not, log this on the server side right when reading the ccd/ file so
the admin in question can see "oh, I overlooked *that* special client".

(Since that happened to a friend of mine based on my advice, I know that
this is not a purely theoretical possibility :-) )

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


signature.asc
Description: PGP signature
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] push: Provide a warning if --ifconfig-push have argument mismatch with --topology

[Gert Doering]

Hi,

On Thu, Dec 01, 2016 at 01:23:52PM +0100, David Sommerseth wrote:
> > (What you can do is "peek at byte 0", which will always be the same
> > part of the netmask [network byte order!], and which might actually
> > make this easier to read .-) )
> 
> You mean like this?
> 
> in_addr_t nmask = htonl(c->c2.push_ifconfig_remote_netmask);
> if ( nmask[0] == 0xff )
>   {
>  ...
> 

No :-) - if you htonl() it, you need to work with full words and 
0xff00 etc. - but if you just peek at 

   ((uchar *)>c2.push_ifconfig_remote_netmask)[0]

you should get the first byte of the netmask, no matter what the 
host byte order is.  (I'm not absolutely sure it's [0], could be [3],
but in any case, since this is "network byte order", location *in 
memory* will not be host byte order dependent)

But right now I'm a bit too busy to properly think about this, and
would just postpone to 2.4.1 - it's really minor.

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


signature.asc
Description: PGP signature
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] push: Provide a warning if --ifconfig-push have argument mismatch with --topology

[Arne Schwabe]

Am 30.11.16 um 23:41 schrieb David Sommerseth:
> This adds a warning to the log file if --topology is configured to use
> subnet or net30 and the 'subnet mask' argument of an --ifconfig-push option
> is not an subnet mask.  The check done is to ensure the first octet is 0xff 
> (255)
>
>
But way you actually want to test is

if topology == subnet or net30:
   if gateway not in net(ip, mask):
  print ("Your gw and ip and netmask disagree!)

right? And isn't there code that gets executed for the client side that
can be disabled by ifconfig-nowarn. Can we reuse that code?

Arne

--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] push: Provide a warning if --ifconfig-push have argument mismatch with --topology

[David Sommerseth]

On 01/12/16 09:01, Gert Doering wrote:
> Hi,
> 
> On Wed, Nov 30, 2016 at 11:41:27PM +0100, David Sommerseth wrote:
>> +  if ((c->options.topology == TOP_SUBNET || c->options.topology == 
>> TOP_NET30)
>> +  && (c->c2.push_ifconfig_remote_netmask & 0xff00) != 
>> 0xff00)
> 
> Are you sure of that?  I would assume that this is stored in network
> byte order (as it's an in_addr_t) so you can't directly compare it to
> a number but need to run through ntohl() first.
> 
> On *intel* it might end up being the same, but code dealing with IPv4
> addresses and ports always needs to be checked on both endiannesses.

Good point!  I didn't consider endianess too careful, I just looked at
what we do in print_in_addr_t(), realised that we always call it with 0
in the flags argument in same prepare_push_reply() function.

  ia.s_addr = (flags & IA_NET_ORDER) ? addr : htonl (addr);

And now (when I have slightly more brainpower) I see I misread the
logic, so 

> Some random code I just found in a BSD header file does it that way:
> 
> #define INADDR_ALLHOSTS_GROUP   (u_int32_t)0xe001   /* 224.0.0.1 */
> #define in_allhosts(x)  ((x).s_addr == htonl(INADDR_ALLHOSTS_GROUP))   
> 
> ... so it certainly needs the htonl()

... Yes!

> (What you can do is "peek at byte 0", which will always be the same
> part of the netmask [network byte order!], and which might actually
> make this easier to read .-) )

You mean like this?

in_addr_t nmask = htonl(c->c2.push_ifconfig_remote_netmask);
if ( nmask[0] == 0xff )
  {
 ...


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc




signature.asc
Description: OpenPGP digital signature
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] combined ndis5 + ndis6 installer ?

[Samuli Seppänen]

Hi,

Il 30/11/2016 11:58, Илья Шипицин ha scritto:
>
>
> (and, yes, I'm going to build multi-language installer, probably
> right
> after 2.4 release)
>
>
> This makes sense. Any plans on how you're going to do it?
>
>
>
> as we do not support windows 2000 anymore, we can easily switch to unicode.
> there are few questions
>
> 1) unicode nsis under linux (we use windows+mingw+nsis unicode, so, I'm
> not sure about linux)
>

Unicode seems to be present in Linux NSIS versions, according to this:



The build computers need to be updated to a quite recent NSIS version, 
though.


> 2) split installer into several language files (as done for openvpn-gui)

We'd also need to detect the language the user is using to select the 
correct one. I personally don't like manual language selector as they 
add one more step to the install process.

>
> 3) test everything
>
>
> it is not difficult, but it is time consuming, I'm afraid we will test
> it properly before 2.4

The plan is to release 2.5 pretty quickly after 2.4. Also, installer 
changes do not necessarily need to go in sync with OpenVPN releases.

>
> Another internationalization aspect we could improve is how we store
> translations for OpenVPN-GUI. Editing the resource files directly is
> clumsy and error-prone, as the files contain lots of "stuff" that is
> not meant to be translated. A simple key-value file would be much
> easier, although in OpenVPN-GUI's case the hardcoded window sizes
> make this more complex.
>
>
> it makes sense to convert openvpn-gui resources into visual studio format.
> @selvanair some times ago told something like that.

Hmm, interesting, will need to look into it. Any format that could be 
loaded by a translation memory application is better than what we have 
now. Simple key-value resource files are also easy to convert into other 
similar formats, if necessary.

> as for the rest, separate resources are just fine.
>
>
>
> Also I'm not sure how easy it would be to separate the translatable
> strings into a separate file. I would guess that the actual .res
> files could be generated on the fly from a template and the
> key-value file by the build scripts.
>
>
> it looks overcomplicated. some kind of "post build operation" which will
> identifies missing language resources would be nice however

Yeah, it could be hairy. Let's look into this in depth later.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: reload CRL only if file was modified

[Gert Doering]

Your patch has been applied to the master branch.

I've added a Changes.rst entry as discussed on IRC.

commit ce91c187ee0dd73aa4dbe4468181db90403951ce
Author: Antonio Quartulli
Date:   Thu Dec 1 18:41:45 2016 +0800

 reload CRL only if file was modified

 Signed-off-by: Antonio Quartulli 
 Acked-by: Steffan Karger 
 Message-Id: <20161201104145.23821-...@unstable.cc>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13345.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3] reload CRL only if file was modified

[Steffan Karger]

On 01-12-16 11:41, Antonio Quartulli wrote:
> In order to prevent annoying delays upon client connection,
> reload the CRL file only if it was modified since the last
> reload operation.
> If not, keep on using the already stored CRL.
> 
> This change will boost client connection time in instances
> where the CRL file is quite large (dropping from several
> seconds to few milliseconds).
> 
> Cc: Steffan Karger 
> Signed-off-by: Antonio Quartulli 
> ---
> 
> Changes since v2:
> - print warning if stat() on CRL fails
> - abort CRL (re)load if stat() fails
> 
> Changes since v1:
> - move tls_ctx_reload_crl() before any invocation
> - add doxygen-doc for tls_ctx_reload_crl()
> - add check against CRL size file
> - simplify tls_ctx_reload_crl() by removing reload argument
> 
>  src/openvpn/ssl.c | 53 
> ++-
>  src/openvpn/ssl_backend.h |  2 +-
>  src/openvpn/ssl_mbedtls.c |  2 +-
>  src/openvpn/ssl_mbedtls.h |  2 ++
>  src/openvpn/ssl_openssl.c |  2 +-
>  src/openvpn/ssl_openssl.h |  2 ++
>  6 files changed, 59 insertions(+), 4 deletions(-)
> 
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index 7347a78..ec0a189 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -512,6 +512,54 @@ tls_version_parse(const char *vstr, const char *extra)
>  return TLS_VER_BAD;
>  }
>  
> +/**
> + * Load (or possibly reload) the CRL file into the SSL context.
> + * No reload is performed under the following conditions:
> + * - the CRL file was passed inline
> + * - the CRL file was not modified since the last (re)load
> + *
> + * @param ssl_ctx   The TLS context to use when reloading the CRL
> + * @param crl_file  The file name to load the CRL from, or
> + *  "[[INLINE]]" in the case of inline files.
> + * @param crl_inlineA string containing the CRL
> + */
> +static void
> +tls_ctx_reload_crl(struct tls_root_ctx *ssl_ctx, const char *crl_file,
> +const char *crl_file_inline)
> +{
> +  /* if something goes wrong with stat(), we'll store 0 as mtime */
> +  platform_stat_t crl_stat = {0};
> +
> +  /*
> +   * an inline CRL can't change at runtime, therefore there is no need to
> +   * reload it. It will be reloaded upon config change + SIGHUP.
> +   * Use always '1' as dummy timestamp in this case: it will trigger the
> +   * first load, but will prevent any future reload.
> +   */
> +  if (crl_file_inline)
> +{
> +  crl_stat.st_mtime = 1;
> +}
> +  else if (platform_stat(crl_file, _stat) < 0)
> +{
> +  msg(M_WARN, "WARNING: Failed to stat CRL file, not (re)loading CRL.");
> +  return;
> +}
> +
> +  /*
> +   * Store the CRL if this is the first time or if the file was changed since
> +   * the last load.
> +   * Note: Windows does not support tv_nsec.
> +   */
> +  if ((ssl_ctx->crl_last_size == crl_stat.st_size) &&
> +  (ssl_ctx->crl_last_mtime.tv_sec == crl_stat.st_mtime))
> +return;
> +
> +  ssl_ctx->crl_last_mtime.tv_sec = crl_stat.st_mtime;
> +  ssl_ctx->crl_last_size = crl_stat.st_size;
> +  backend_tls_ctx_reload_crl(ssl_ctx, crl_file, crl_file_inline);
> +}
> +
>  /*
>   * Initialize SSL context.
>   * All files are in PEM format.
> @@ -2581,7 +2629,10 @@ tls_process (struct tls_multi *multi,
> ks->state = S_START;
> state_change = true;
>  
> -   /* Reload the CRL before TLS negotiation */
> +   /*
> +* Attempt CRL reload before TLS negotiation. Won't be performed if
> +* the file was not modified since the last reload
> +*/
> if (session->opt->crl_file &&
> !(session->opt->ssl_flags & SSLF_CRL_VERIFY_DIR))
>   {
> diff --git a/src/openvpn/ssl_backend.h b/src/openvpn/ssl_backend.h
> index 0777c61..3fbd2b4 100644
> --- a/src/openvpn/ssl_backend.h
> +++ b/src/openvpn/ssl_backend.h
> @@ -353,7 +353,7 @@ void key_state_ssl_free(struct key_state_ssl *ks_ssl);
>   *  "[[INLINE]]" in the case of inline files.
>   * @param crl_inlineA string containing the CRL
>   */
> -void tls_ctx_reload_crl(struct tls_root_ctx *ssl_ctx,
> +void backend_tls_ctx_reload_crl(struct tls_root_ctx *ssl_ctx,
>  const char *crl_file, const char *crl_inline);
>  
>  /**
> diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
> index 7fa35a7..11ee65b 100644
> --- a/src/openvpn/ssl_mbedtls.c
> +++ b/src/openvpn/ssl_mbedtls.c
> @@ -771,7 +771,7 @@ static void tls_version_to_major_minor(int tls_ver, int 
> *major, int *minor) {
>  }
>  
>  void
> -tls_ctx_reload_crl(struct tls_root_ctx *ctx, const char *crl_file,
> +backend_tls_ctx_reload_crl(struct tls_root_ctx *ctx, const char *crl_file,
>  const char *crl_inline)
>  {
>ASSERT (crl_file);
> diff --git a/src/openvpn/ssl_mbedtls.h b/src/openvpn/ssl_mbedtls.h
> index 3edeedc..a4a7f05 100644
> --- a/src/openvpn/ssl_mbedtls.h
> +++ b/src/openvpn/ssl_mbedtls.h
> @@ -74,6 +74,8 @@ struct 

[Openvpn-devel] [PATCH v3] reload CRL only if file was modified

[Antonio Quartulli]

In order to prevent annoying delays upon client connection,
reload the CRL file only if it was modified since the last
reload operation.
If not, keep on using the already stored CRL.

This change will boost client connection time in instances
where the CRL file is quite large (dropping from several
seconds to few milliseconds).

Cc: Steffan Karger 
Signed-off-by: Antonio Quartulli 
---

Changes since v2:
- print warning if stat() on CRL fails
- abort CRL (re)load if stat() fails

Changes since v1:
- move tls_ctx_reload_crl() before any invocation
- add doxygen-doc for tls_ctx_reload_crl()
- add check against CRL size file
- simplify tls_ctx_reload_crl() by removing reload argument

 src/openvpn/ssl.c | 53 ++-
 src/openvpn/ssl_backend.h |  2 +-
 src/openvpn/ssl_mbedtls.c |  2 +-
 src/openvpn/ssl_mbedtls.h |  2 ++
 src/openvpn/ssl_openssl.c |  2 +-
 src/openvpn/ssl_openssl.h |  2 ++
 6 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 7347a78..ec0a189 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -512,6 +512,54 @@ tls_version_parse(const char *vstr, const char *extra)
 return TLS_VER_BAD;
 }
 
+/**
+ * Load (or possibly reload) the CRL file into the SSL context.
+ * No reload is performed under the following conditions:
+ * - the CRL file was passed inline
+ * - the CRL file was not modified since the last (re)load
+ *
+ * @param ssl_ctx   The TLS context to use when reloading the CRL
+ * @param crl_file  The file name to load the CRL from, or
+ *  "[[INLINE]]" in the case of inline files.
+ * @param crl_inlineA string containing the CRL
+ */
+static void
+tls_ctx_reload_crl(struct tls_root_ctx *ssl_ctx, const char *crl_file,
+  const char *crl_file_inline)
+{
+  /* if something goes wrong with stat(), we'll store 0 as mtime */
+  platform_stat_t crl_stat = {0};
+
+  /*
+   * an inline CRL can't change at runtime, therefore there is no need to
+   * reload it. It will be reloaded upon config change + SIGHUP.
+   * Use always '1' as dummy timestamp in this case: it will trigger the
+   * first load, but will prevent any future reload.
+   */
+  if (crl_file_inline)
+{
+  crl_stat.st_mtime = 1;
+}
+  else if (platform_stat(crl_file, _stat) < 0)
+{
+  msg(M_WARN, "WARNING: Failed to stat CRL file, not (re)loading CRL.");
+  return;
+}
+
+  /*
+   * Store the CRL if this is the first time or if the file was changed since
+   * the last load.
+   * Note: Windows does not support tv_nsec.
+   */
+  if ((ssl_ctx->crl_last_size == crl_stat.st_size) &&
+  (ssl_ctx->crl_last_mtime.tv_sec == crl_stat.st_mtime))
+return;
+
+  ssl_ctx->crl_last_mtime.tv_sec = crl_stat.st_mtime;
+  ssl_ctx->crl_last_size = crl_stat.st_size;
+  backend_tls_ctx_reload_crl(ssl_ctx, crl_file, crl_file_inline);
+}
+
 /*
  * Initialize SSL context.
  * All files are in PEM format.
@@ -2581,7 +2629,10 @@ tls_process (struct tls_multi *multi,
  ks->state = S_START;
  state_change = true;
 
- /* Reload the CRL before TLS negotiation */
+ /*
+  * Attempt CRL reload before TLS negotiation. Won't be performed if
+  * the file was not modified since the last reload
+  */
  if (session->opt->crl_file &&
  !(session->opt->ssl_flags & SSLF_CRL_VERIFY_DIR))
{
diff --git a/src/openvpn/ssl_backend.h b/src/openvpn/ssl_backend.h
index 0777c61..3fbd2b4 100644
--- a/src/openvpn/ssl_backend.h
+++ b/src/openvpn/ssl_backend.h
@@ -353,7 +353,7 @@ void key_state_ssl_free(struct key_state_ssl *ks_ssl);
  *  "[[INLINE]]" in the case of inline files.
  * @param crl_inlineA string containing the CRL
  */
-void tls_ctx_reload_crl(struct tls_root_ctx *ssl_ctx,
+void backend_tls_ctx_reload_crl(struct tls_root_ctx *ssl_ctx,
 const char *crl_file, const char *crl_inline);
 
 /**
diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index 7fa35a7..11ee65b 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -771,7 +771,7 @@ static void tls_version_to_major_minor(int tls_ver, int 
*major, int *minor) {
 }
 
 void
-tls_ctx_reload_crl(struct tls_root_ctx *ctx, const char *crl_file,
+backend_tls_ctx_reload_crl(struct tls_root_ctx *ctx, const char *crl_file,
 const char *crl_inline)
 {
   ASSERT (crl_file);
diff --git a/src/openvpn/ssl_mbedtls.h b/src/openvpn/ssl_mbedtls.h
index 3edeedc..a4a7f05 100644
--- a/src/openvpn/ssl_mbedtls.h
+++ b/src/openvpn/ssl_mbedtls.h
@@ -74,6 +74,8 @@ struct tls_root_ctx {
 mbedtls_x509_crt *ca_chain;/**< CA chain for remote 
verification */
 mbedtls_pk_context *priv_key;  /**< Local private key */
 mbedtls_x509_crl *crl;  /**< Certificate Revocation List */
+struct timespec crl_last_mtime; /**< 

Re: [Openvpn-devel] [PATCH v2] reload CRL only if file was modified

[Steffan Karger]

On 01-12-16 09:13, Steffan Karger wrote:
>   else if (0 != platform_stat(crl_file, _stat))
> {
>   msg (M_WARN, "WARNING: Failed to stat CRL file, using cached CRL.");
> }

Ahum, as Gert noted on IRC, this missed a return statement to actually
*not* load the CRL.  So, better suggestion:

  else if (platform_stat(crl_file, _stat) < 0)
{
  msg (M_WARN, "WARNING: Failed to stat CRL file, using (re)loading
CRL.");
  return;
}

-Steffan

--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] reload CRL only if file was modified

[Antonio Quartulli]

On Thu, Dec 01, 2016 at 09:13:36AM +0100, Steffan Karger wrote:
> Hi,
> 
> Tested on linux and windows, works as expected, except for one thing:
> 
> On 01-12-16 07:55, Antonio Quartulli wrote:
> > +  /*
> > +   * an inline CRL can't change at runtime, therefore there is no need to
> > +   * reload it. It will be reloaded upon config change + SIGHUP.
> > +   * Use always '1' as dummy timestamp in this case: it will trigger the
> > +   * first load, but will prevent any future reload.
> > +   */
> > +  if (crl_file_inline)
> > +crl_stat.st_mtime = 1;
> > +  else
> > +platform_stat(crl_file, _stat);
> 
> I still think this should issue a warning when we do not reload the CRL
> because platform_stat() fails, e.g. due to the CRL file missing.  So, if
> we replace this with:
> 
>   if (crl_file_inline)
> {
>   crl_stat.st_mtime = 1;
> }
>   else if (0 != platform_stat(crl_file, _stat))
> {
>   msg (M_WARN, "WARNING: Failed to stat CRL file, using cached CRL.");
> }
> 
> I can ACK this.
> 
> Since the deadline for 2.4_rc1 is this afternoon (CET), and Antonio
> seems to be awake at quite different times than the Europeans doing the
> tagging, maybe one of the committers can make this change on the file if
> he agrees?  Of course, if Antonio does read this in time, a v3 would be
> even better!

v3 is coming ;)

> 
> Thanks,
> -Steffan
> 
> --
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 

-- 
Antonio Quartulli

--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Do not restart dns client service as a part of --register-dns processing

[Gert Doering]

ACK, thanks.

Code looks good, and test compiles.  Have not test-run yet but do not
expect any surprises there.

I have added a Changes.rst entry (someone *might* notice and wonder if
this was intentional :) ) and updated doc/openvpn.8 and the help text
in options.c which both used to list all the commands run...

Your patch has been applied to the master branch.

commit fb56058a98dcc81b34cffbdc46417d672b8926e1
Author: Selva Nair
Date:   Wed Nov 30 16:51:36 2016 -0500

 Do not restart dns client service as a part of --register-dns processing

 Signed-off-by: Selva Nair 
 Acked-by: Gert Doering 
 Message-Id: <1480542696-7123-1-git-send-email-selva.n...@gmail.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13331.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] reload CRL only if file was modified

[Steffan Karger]

Hi,

Tested on linux and windows, works as expected, except for one thing:

On 01-12-16 07:55, Antonio Quartulli wrote:
> +  /*
> +   * an inline CRL can't change at runtime, therefore there is no need to
> +   * reload it. It will be reloaded upon config change + SIGHUP.
> +   * Use always '1' as dummy timestamp in this case: it will trigger the
> +   * first load, but will prevent any future reload.
> +   */
> +  if (crl_file_inline)
> +crl_stat.st_mtime = 1;
> +  else
> +platform_stat(crl_file, _stat);

I still think this should issue a warning when we do not reload the CRL
because platform_stat() fails, e.g. due to the CRL file missing.  So, if
we replace this with:

  if (crl_file_inline)
{
  crl_stat.st_mtime = 1;
}
  else if (0 != platform_stat(crl_file, _stat))
{
  msg (M_WARN, "WARNING: Failed to stat CRL file, using cached CRL.");
}

I can ACK this.

Since the deadline for 2.4_rc1 is this afternoon (CET), and Antonio
seems to be awake at quite different times than the Europeans doing the
tagging, maybe one of the committers can make this change on the file if
he agrees?  Of course, if Antonio does read this in time, a v3 would be
even better!

Thanks,
-Steffan

--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: Force 'def1' method when --redirect-gateway is done through service

[Gert Doering]

Hi,

On Wed, Nov 30, 2016 at 11:06:02PM +0100, Arne Schwabe wrote:
> Slight correction. We actually set 0.0.0.0/0 on Android but Android
> *always* translates that into a 0.0.0.0/1 and a 128.0.0.0/1 rule.
> 
> We could do the same and do the translation in the interactive service
> instead of OpenVPN itself.

We could, but that wouldn't solve the issue of OpenVPN trying to 
remove the existing default route (which we would have to special-case-and-
ignore) and reinstall it later on (which must not be translated to
2x /1, but ignored as well).

The service code doesn't know whether a route is "for the VPN API" or
"for anything else" (which openvpn on "non VPN API" platforms always
could do) so this would be a much more intrusive 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


signature.asc
Description: PGP signature
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] push: Provide a warning if --ifconfig-push have argument mismatch with --topology

[Gert Doering]

Hi,

On Thu, Dec 01, 2016 at 05:15:11AM +0300, SviMik wrote:
> While I admit that it is *extremely* unlikely to have a network larger than 
> /8, such logic still looks a little clumsy. It does not cover all the valid 
> netmasks neither it detects all possible invalid ones.

This is true, but not really relevant.  Right now, it will just do funky
things, and there is no indication in the logs where to look.

Nobody uses non-contiguous netmasks these days (like "240.0.255.0"),
so everything *normal* starts with a string of 1-bits, and a valid IPv4
address never starts with , so checking for "255." at the start
of something that could be "a netmask or a remote IPv4 address" will
get it right in about all cases we care about.

If someone insists on doing a /7 on their tun interface, they better
know really well what they are doing.

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


signature.asc
Description: PGP signature
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] push: Provide a warning if --ifconfig-push have argument mismatch with --topology

[Gert Doering]

Hi,

On Wed, Nov 30, 2016 at 11:41:27PM +0100, David Sommerseth wrote:
> +  if ((c->options.topology == TOP_SUBNET || c->options.topology == 
> TOP_NET30)
> +  && (c->c2.push_ifconfig_remote_netmask & 0xff00) != 0xff00)

Are you sure of that?  I would assume that this is stored in network
byte order (as it's an in_addr_t) so you can't directly compare it to
a number but need to run through ntohl() first.

On *intel* it might end up being the same, but code dealing with IPv4
addresses and ports always needs to be checked on both endiannesses.

Some random code I just found in a BSD header file does it that way:

#define INADDR_ALLHOSTS_GROUP   (u_int32_t)0xe001   /* 224.0.0.1 */
#define in_allhosts(x)  ((x).s_addr == htonl(INADDR_ALLHOSTS_GROUP))   

... so it certainly needs the htonl()

(What you can do is "peek at byte 0", which will always be the same
part of the netmask [network byte order!], and which might actually
make this easier 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


signature.asc
Description: PGP signature
--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel