On Thursday, November 10, 2016 4:01:20 PM CET David Sommerseth wrote:
> On 28/10/16 18:42, Heiko Hund wrote:
> >
> > + a->gc = gc_new ();
> >argv_extend (a, 8);
> > }
>
> Any specific reason we want to keep our own gc_arena on argv? Why not
> pass an existing gc_arena pointer to the argv_n
Hi,
On 11-11-17 17:18, Antonio Quartulli wrote:
> *-inline.h files are not very useful anymore.
> In the attempt of cleaning up the code some more,
> merge them into their main header files.
>
> No functional change is part of this patch.
>
> Cc: Steffan Karger
> Signed-off-by: Antonio Quartull
On Wednesday, November 9, 2016 11:58:21 PM CET David Sommerseth wrote:
> > argv_init (struct argv *a)
> > {
> >
> >a->capacity = 0;
> >a->argc = 0;
> >a->argv = NULL;
> >
> > + argv_extend (a, 8);
>
> Why 8? Done any performance and/or memory utilization tests? Does the
> overa
Hi,
On 11/11/17 23:36, Steffan Karger wrote:
> From: Steffan Karger
>
> This allows the user to specify what certificate crypto algorithms to
> support. The supported profiles are 'preferred', 'legacy' (default) and
> 'suiteb', as discussed in <84590a17-1c48-9df2-c48e-4160750b2...@fox-it.com>
>
Hi,
On 11/11/17 23:36, Steffan Karger wrote:
> From: Steffan Karger
>
> This allows the user to specify what certificate crypto algorithms to
> support. The supported profiles are 'preferred', 'legacy' (default) and
> 'suiteb', as discussed in <84590a17-1c48-9df2-c48e-4160750b2...@fox-it.com>
>
Hi David,
On Wednesday, November 9, 2016 9:41:21 PM CET David Sommerseth wrote:
> In the new argv_prep_format() function:
>
> + if (!in_token)
> +{
> + ++*count;
> + if (f[0])
> +f[j++] = delim;
> +}
>
> What is the purpose of the f[0] check? A
Hi,
On 11-11-17 18:14, Gert van Dijk wrote:
> I think this was omitted in 66bf378e.
>
> Signed-off-by: Gert van Dijk
> ---
> .gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.gitignore b/.gitignore
> index 18a45202..25009d81 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@
I think this was omitted in 66bf378e.
Signed-off-by: Gert van Dijk
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 18a45202..25009d81 100644
--- a/.gitignore
+++ b/.gitignore
@@ -52,6 +52,7 @@ config-msvc-version.h
doc/openvpn.8.html
/doc/doxyge
Hi,
On 11-11-17 17:18, Antonio Quartulli wrote:
> In the attempt of getting rid of any pf-inline.h file, we need
> to make sure that inline functions do not trigger any circular
> include dependency.
>
> For this reason, avoid pf_c2c/addr_test() to be 'struct context'
> aware, so that pf-inline.h
Hi,
Some of these changes are of dubious value as the string lengths
involved are guaranteed to be small and there is no scope
for overflow. And casting only stops the compiler warning, not potential
overflow, if any..
As for the offending mixed int/size_t arithmetic, a better option is
to just t
This can be used to redirect all IPv6 traffic to the tun interface, effectively
black holing the IPv6 traffic. Without ICMPv6 error messages this will result
in timeouts when the server does not send error codes.
block-ipv6 allows client side only blocking on all platforms that OpenVPN
supports
From: Antonio Quartulli
Function prototypes should be included when compiling their
definitions so that it is clear to compilers and static
analyzers that they are not static.
This means that several declarations have to be moved to the
related header files which in turn have to be included by t
*-inline.h files are not very useful anymore.
In the attempt of cleaning up the code some more,
merge them into their main header files.
No functional change is part of this patch.
Cc: Steffan Karger
Signed-off-by: Antonio Quartulli
---
v4: pf_c2c/addr_test() has been made static again
v5: no
In the attempt of getting rid of any pf-inline.h file, we need
to make sure that inline functions do not trigger any circular
include dependency.
For this reason, avoid pf_c2c/addr_test() to be 'struct context'
aware, so that pf-inline.h does not need to rely on the content
of openvpn.h.
Cc: Stef
Hi François,
This is not a full review, but as just discussed face-to-face, here are
some points from me:
1) Could we also please please enable this for non-management interface
use case? I guess it's just adding the status version number 4 in
option/config validator (and the manpage).
2) With 1)
Signed-off-by: Gert van Dijk
---
doc/openvpn.8 | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index a4189ac2..267497fd 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -2452,12 +2452,37 @@ seconds.
Status can al
With NCP turned off, this will still display the cipher used.
Trac: #814
Signed-off-by: Gert van Dijk
---
doc/openvpn.8 | 2 +-
src/openvpn/multi.c | 11 +++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 267497fd..00dbff6f 1006
P_DATA_V2 introduced the peer-id. This allows clients to float, but as a
side-effect 32-bit aligns the encrypted data. That alignment improves
performance particularly on cheaper/older CPUs. So although servers don't
actually have a peer-id, still use the V2 packet format (with a zero-id)
for se
From: Steffan Karger
This allows the user to specify what certificate crypto algorithms to
support. The supported profiles are 'preferred', 'legacy' (default) and
'suiteb', as discussed in <84590a17-1c48-9df2-c48e-4160750b2...@fox-it.com>
(https://www.mail-archive.com/openvpn-devel@lists.sourcef
Patch has been applied to the master and release/2.4 branch (with
the whitespace change as suggested by our styleguide enforcer :) ).
commit 7a216d9dba558281d4b6a04124912081a79fcb88 (master)
commit 81b6882116a55299d5da5542d757d65384829efe (release/2.4)
Author: Gert Doering
Date: Sat Nov 11 15:22
Hi,
On 11-11-17 15:22, Gert Doering wrote:
> tun-ipv6 is a no-op nowadays, and we print a warning to let users know -
> which is not helpful for server-pushed tun-ipv6 (which might be the
> result of --server-ipv6 automatically pushing this). So, remove the
> warning if parsing pushed options.
>
Am 11.11.17 um 15:22 schrieb Gert Doering:
> tun-ipv6 is a no-op nowadays, and we print a warning to let users know -
> which is not helpful for server-pushed tun-ipv6 (which might be the
> result of --server-ipv6 automatically pushing this). So, remove the
> warning if parsing pushed options.
>
tun-ipv6 is a no-op nowadays, and we print a warning to let users know -
which is not helpful for server-pushed tun-ipv6 (which might be the
result of --server-ipv6 automatically pushing this). So, remove the
warning if parsing pushed options.
Also, remove the VERIFY_PERMISSION() call here which
Hi,
On Sat, Nov 11, 2017 at 03:16:13PM +0100, Steffan Karger wrote:
> (I'll leave review of the correctness of the change to someone who
> actually understands what tun-ipv6 exactly does.)
"exactly and absolutely nothing" :-)
(It *used* to be a flag to tell openvpn "switch the tun interface into
Hi,
On 11-11-17 14:36, Gert Doering wrote:
> tun-ipv6 is a no-op nowadays, and we print a warning to let users know -
> which is not helpful for server-pushed tun-ipv6 (which might be the
> result of --server-ipv6 automatically pushing this). So, remove the
> warning if parsing pushed options.
>
tun-ipv6 is a no-op nowadays, and we print a warning to let users know -
which is not helpful for server-pushed tun-ipv6 (which might be the
result of --server-ipv6 automatically pushing this). So, remove the
warning if parsing pushed options.
Also, remove the VERIFY_PERMISSION() call here which
From: Simon Matter
While we were suffering from the "TLS Renegotiation Slowdown" bug here
https://community.openvpn.net/openvpn/ticket/854 we realized that there is
still room for improvement in our use case.
It appears that TLS renegotiation is getting more and more expensive in
terms of CPU cy
27 matches
Mail list logo
