How about printenv (without grep)?
From: Christian Hesse
Sent: Monday, January 6, 2020 4:04:26 PM
To: OpenVPN Development
Cc: Christian Hesse
Subject: [Openvpn-devel] [PATCH 1/1] configure.ac: replace set with env
From: Christian Hesse
The shell builtin `set`
used with `--server`, for simplicity and consistency. (In addition to
the consistency of whether --server can be used with `--ip-win32
dynamic`, x.x.x.254 may actually be used in a tap set-up, rendering
commit 251cc8f "wrong".
On Wed, 13 Nov 2019 at 19:41, Tom Yan wrote:
>
>
If it isn't a typo, I wonder if it is the equivalence of
`pool_end_reserve`. As with the subnet topology, each client takes up
1 address in contrast to 4 with net30.
So perhaps the question is, what's the purpose of pool_end_reserve?
On Wed, 13 Nov 2019 at 18:07, Tom Yan wrote:
>
As /31 subnet now works (as we stop setting broadcast address), the server
directives can be fixed for it as well.
---
src/openvpn/helper.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/src/openvpn/helper.c b/src/openvpn/helper.c
index 470b9120..5b2ca0cc
It appears to be a copy-and-paste kind of typo (pool start is network address +
2).
---
src/openvpn/helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/openvpn/helper.c b/src/openvpn/helper.c
index 5b2ca0cc..6e2f0891 100644
--- a/src/openvpn/helper.c
+++ b/src/openvpn
It also avoids limitation (i.e. netbits <= 29) that does not apply to the
subnet topology.
---
src/openvpn/helper.c | 74
1 file changed, 27 insertions(+), 47 deletions(-)
diff --git a/src/openvpn/helper.c b/src/openvpn/helper.c
index ff9df506..470b91
The setting probably just slipped out of the if-block over rewrites.
---
src/openvpn/helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/openvpn/helper.c b/src/openvpn/helper.c
index 6e2f0891..a36bc63a 100644
--- a/src/openvpn/helper.c
+++ b/src/openvpn/helper.c
@@ -35
On Wed, 13 Nov 2019 at 17:18, Gert Doering wrote:
>
> Hi,
>
> It might be related to the way the windows tap6 driver always needs a
> gateway address even in tun mode (and uses the last address from the
> subnet for this). There's very few typos in OpenVPN code regarding
> *this* type of math, an
sk` need to be set even
when `nopool` is set?
On Wed, 13 Nov 2019 at 16:59, Tom Yan wrote:
>
> As /31 subnet now works (as we stop setting broadcast address), the server
> directives can be fixed for it as well. Also stop repeating code for tap and
> tun + subnet.
As /31 subnet now works (as we stop setting broadcast address), the server
directives can be fixed for it as well. Also stop repeating code for tap and
tun + subnet.
---
src/openvpn/helper.c | 90 ++--
1 file changed, 37 insertions(+), 53 deletions(-)
dif
the route is not in effect (but still added),
and therefore for it to be able to reach the server, I would need to
push/configure a route explicitly.
On Tue, 12 Nov 2019 at 02:02, Arne Schwabe wrote:
>
> Am 11.11.19 um 16:12 schrieb Tom Yan:
> > Yes both iproute2 and sitnl works perfe
0:12AM +0800, Tom Yan wrote:
> > So in master, when net_addr_v4_add is called in tun.c, which
> > net_addr_v4_add (networking_iproute2.c or networking_sitnl.c) is
> > actually used depends on how openvpn is built, right?
>
> Can you have a look at the current "maste
Hmm btw, not sure you are talking about the same thing, but at least
my device the "proto kernel scope link" subnet route is added for the
tun. While I can ping the "peer" out-of-the-box with /31 subnet and
the subnet topology, with p2p topology and 255.255.255.255 mask, I
need to add route in ics-
Yeah I was merely referring to the trivial warning of the ifconfig mismatch.
It's not exactly a problem but it just sort of made me aware of such thing as
/31 subnet and noticed the bug on Linux. That's why I never opened an issue on
ics-openvpn.
From: Arne Schwa
n the server directive, which should be fixed in a follow-up;
but it's not like users have to use that anyway.)
On Mon, 4 Nov 2019 at 04:46, Gert Doering wrote:
>
> Hi,
>
> On Mon, Nov 04, 2019 at 03:54:49AM +0800, Tom Yan wrote:
> > While the commit message says "
While the commit message says "support" 31-bit prefix, this patch is a
bug fix by nature. Whether one can actually uses a /31 subnet for
*anything* (i.e. not just OpenVPN) pretty much depends entirely on the
platform itself. This patch is needed simply because broadcast address
does not "apply" in
Btw, is there a particular reason that we don't simply use "broadcast
+" and let `ip` handle it? We won't even need to do the prefix length
check if we aren't setting the broadcast address explicitly.
Regards,
On Sun, 3 Nov 2019 at 19:32, Tom Yan wrote:
>
> Hell
it with the above as its commit message.
Regards,
Tom
On Sun, 3 Nov 2019 at 18:43, Antonio Quartulli wrote:
>
> Hi Tom,
>
> first of all, thanks a lot for your contribution!
>
> On 03/11/2019 06:30, Tom Yan wrote:
> > ---
> > src/openvpn/networking_iproute2.c | 6 ++
---
src/openvpn/tun.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 80eaa2c4..f5823516 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -965,13 +965,14 @@ do_ifconfig(struct tuntap *tt,
else
{
---
src/openvpn/networking_iproute2.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/openvpn/networking_iproute2.c
b/src/openvpn/networking_iproute2.c
index 1ddeb5cf..4e2435c1 100644
--- a/src/openvpn/networking_iproute2.c
+++ b/src/openvpn/networking_iproute2.c
@@
20 matches
Mail list logo
