I had conflicts in doc/management-notes.txt (the context leading to
this in the patch is way different, and not in my tree?!), and uncrustify
had some whitespace complaints - fixed the conflict, and the complaints.
Stare-at-code looks reasonable ("and it has an ACK from Arne").
I have tested this
The patch needed a bit of convincing to go in (context change in options.h,
and braces-in-the-wrong-line). Fixed.
Tested with a config with 200 somewhat random remote lines - without the
patch
Options error: Maximum number of 'remote' options (64) exceeded
and with the patch "it just works"..
Removed the hunk related to "client-pf". The rest went in just fine.
Verified with my favourite "why does this not work at --management-hold
time?" new command :-)
>HOLD:Waiting for hold release:0
remote-entry-count
ERROR: The 'remote-entry-count' command is not supported by the curr
Hi,
On Mon, Dec 26, 2022 at 05:30:23PM -0500, Selva Nair wrote:
> > > +
> > > +#define min(a,b) ((a) < (b) ? (a) : (b))
> >
> > We already have min_int and min_uint in integer.h. For consistency I
> > would prefer using those instead of adding a macro.
Unfortunately, this is more than "just an ex
We really shouldn't let patches linger for so long... the options.h hunk
had context that now looks completely different, both up and down...
Looking at the code, I do wonder why we increase the unsuccessful_attempts
by the number of entries *skipped*
-c->options.unsuccessful_atte
Hi,
On Tue, Dec 27, 2022 at 03:24:04AM +0100, Arne Schwabe wrote:
> This enables logging the peer id in p2mp mode if dco is enabled
> and the log level is high enough
Ho hum, this does not work for me...
TLS/TCP server, DCO enabled, --verb 6...
2022-12-27 11:05:41 us=111855 something/194.97.140
The realloc logic has the problem that it relies on the memory being
deallocated by uninit_options rather than by freeing the gc. This
does not always happen in all code path. Especially the crypto selftest
run by make check will not call uninit_options.
This introduces a gc_realloc function that
Signed-off-by: Arne Schwabe
---
src/openvpn/manage.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index be9a38952..7e326702f 100644
--- a/src/openvpn/manage.c
+++ b/src/openvpn/manage.c
@@ -865,8 +865,6 @@ man_remote_
with dco sometimes we end up promoting a timeout event to read event.
For the residual read, this problem is probably not solvable without
changing the kernel DCO API (ie. passing our residual on new_peer to
let the kernel handle assembling the next packet.)
Signed-off-by: Arne Schwabe
---
src/o
Signed-off-by: Arne Schwabe
---
src/openvpn/multi.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 6c6385c6e..50d88f19a 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -3243,10 +3243,19 @@ proces
This enables logging the peer id in p2mp mode if dco is enabled
and the log level is high enough
Signed-off-by: Arne Schwabe
---
src/openvpn/multi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 50d88f19a..f8366be28 100644
--- a/src/ope
Instead of getting the server in a very weird state, we bail out here. This
is only a bandaid solution but better than the alternatives.
Signed-off-by: Arne Schwabe
---
src/openvpn/mtcp.c | 2 +-
src/openvpn/multi.c | 10 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git
Hi,
On Tue, Dec 27, 2022 at 03:24:01AM +0100, Arne Schwabe wrote:
> with dco sometimes we end up promoting a timeout event to read event.
> For the residual read, this problem is probably not solvable without
> changing the kernel DCO API (ie. passing our residual on new_peer to
> let the kernel h
Acked-by: Gert Doering
I have not actually seen this particular race (or if I have seen it it
was drowned in lots of other events) - but yeah, to fully ignore this
seems better than "kill peer just because we ended a peer with
the very same peer-id a few seconds ago".
To achieve the "some othe
Hi,
On Tue, Dec 27, 2022 at 4:47 AM Gert Doering wrote:
> Looking at the code, I do wonder why we increase the unsuccessful_attempts
> by the number of entries *skipped*
>
> -c->options.unsuccessful_attempts++;
> +c->options.unsuccessful_attempts += advance_count;
Acked-by: Gert Doering
Thanks.
Have not done much testing beyond "push to github and enjoy the green"
(but this is very nice indeed). Well, except for the clang-asan red,
which I did not notice before... but there is 2/2 for that :-)
Your patch has been applied to the master branch.
commit 8
Hi,
On Mon, Dec 26, 2022 at 05:30:23PM -0500, Selva Nair wrote:
> > > > +
> > > > +#define min(a,b) ((a) < (b) ? (a) : (b))
> > >
> > > We already have min_int and min_uint in integer.h. For consistency I
> > > would prefer using those instead of adding a macro.
Unfortunately, this is more than
Hi,
On Tue, Dec 27, 2022 at 01:18:02PM -0500, Selva Nair wrote:
> My test implementation in the GUI constructs the list when first >REMOTE
> query is received. If there is no >REMOTE from the daemon, the feature is
> not used. That works.
So what's the magic --option to make openvpn query for >RE
On Tue, Dec 27, 2022 at 1:25 PM Gert Doering wrote:
> Hi,
>
> On Tue, Dec 27, 2022 at 01:18:02PM -0500, Selva Nair wrote:
> > My test implementation in the GUI constructs the list when first >REMOTE
> > query is received. If there is no >REMOTE from the daemon, the feature is
> > not used. That w
Acked-by: Gert Doering
The initial tests were left to Github/ASAN builds, which are now
"all green for real" -
https://github.com/cron2/openvpn/actions/runs/3789030448
Stare-at-code also looks good, though a bit complicated (and if I'm
reading this right, doing an initial allocation with gc_
Am 22.12.22 um 10:53 schrieb Gert Doering:
TCP multipoint servers with Linux-DCO can crash under yet-unknown
circumstances where a TCP socket gets handed to the kernel (= userland
shall not acceess it again) but the socket still lands in the event
polling mechanism, and is passed to link_socket_r
TCP multipoint servers with Linux-DCO can crash under yet-unknown
circumstances where a TCP socket gets handed to the kernel (= userland
shall not acceess it again) but the socket still lands in the event
polling mechanism, and is passed to link_socket_read() with
sock->fd being "-1" (SOCKET_UNDEFI
Am 27.12.22 um 21:26 schrieb Gert Doering:
TCP multipoint servers with Linux-DCO can crash under yet-unknown
circumstances where a TCP socket gets handed to the kernel (= userland
shall not acceess it again) but the socket still lands in the event
polling mechanism, and is passed to link_socket_r
Patch has been applied to the master and release/2.6 branch.
commit c7416160fb2e5a66d5801e4b789751a7480e6384 (master)
commit b17cbbdab0f81dd7d54db8786adfffa70b87e1d6 (HEAD -> release/2.6)
Author: Gert Doering
Date: Tue Dec 27 21:26:14 2022 +0100
bandaid fix for TCP multipoint server crash
commit 5e19cc2c1bf22d introduced a workaround for a race condition
that showed itself on IPv6 ifconfig on FreeBSD 12.x - sometimes breaking
IPv6 connectivity on tun/tap interfaces.
This was fixed on the FreeBSD side in 12.4, 13.1 and up, and 13.0 is
no longer supported. So conditionalize the work
25 matches
Mail list logo
