Am 24.03.23 um 22:12 schrieb Selva Nair:
Hi,
On Fri, Mar 24, 2023 at 4:18 PM Matthias Andree
wrote:
Am 23.03.23 um 15:31 schrieb Frank Lichtenheld:
> Currently this is not obvious since we never build the
> UTs with MSVC, but it doesn't like the initializers with
> "const"
Hi,
On Fri, Mar 24, 2023 at 4:18 PM Matthias Andree
wrote:
> Am 23.03.23 um 15:31 schrieb Frank Lichtenheld:
> > Currently this is not obvious since we never build the
> > UTs with MSVC, but it doesn't like the initializers with
> > "const" variables. They cause
> > error C2099: initializer is
Am 23.03.23 um 15:31 schrieb Frank Lichtenheld:
Currently this is not obvious since we never build the
UTs with MSVC, but it doesn't like the initializers with
"const" variables. They cause
error C2099: initializer is not a constant
What MSVC version are you using? What options? I've tried
Hi,
On Thu, Mar 23, 2023 at 10:31 AM Frank Lichtenheld
wrote:
> Currently this is not obvious since we never build the
> UTs with MSVC, but it doesn't like the initializers with
> "const" variables. They cause
> error C2099: initializer is not a constant
> when used in an initializer.
> So
Hi,
On Fri, Mar 24, 2023 at 09:38:16AM +0100, Gert Doering wrote:
> The previous commit (e86bc8b2967) breaks compilation if all compression
> algorithms are disabled (--disable-lz4 --disable-lzo). A later patch
> in the series would fix this but can not be merged yet.
Just for reference, this
Acked-by: Gert Doering
"Because it makes sense". We didn't discover this before as it needs
a server actually pushing sock-options *and* a DCO-on-Windows client
(*and* TCP?).
I haven't actually tested this, but discussed this beforehand with
Lev, and he has (and the change looks good).
Your
Acked-by: Gert Doering
This is best viewed with "--color-moved=zebra", as it really just moves
stuff around (and gets rid of a few #ifdef USE_COMP). That we now
have #include statements after code is a big ugly, but saves having
another set of #ifdef...
Client-tested with and without
From: Lev Stipakov
Socket flags can be pushed, in which case they overwrite
existing value. We use socket flags to distingust between
DCO handle and socket on Windows. If server pushes --socket-flags,
we treat DCO handle as socket and everything explodes.
Fix by making
This change keeps the option parsing of compression options even when
compression is disabled. This allows OpenVPN to also refuse/reject connections
that try to use compression when compression is completely disabled.
Patch v4: fix one missing USE_COMP
Change-Id:
Hi,
On Thu, Mar 23, 2023 at 06:06:01PM +0100, Arne Schwabe wrote:
> This change keeps the option parsing of compression options even when
> compression is disabled. This allows OpenVPN to also refuse/reject connections
> that try to use compression when compression is completely disabled.
Acked-by: Gert Doering
This is the actual thing we want to fix: if a server pushes 'comp-lzo no',
a non-DCO client will enable compression framing, while a DCO client can
not do this, and silently stays on "no framing" - and then both sides
will drop all data packets because "incorrect format".
This changes the "no" setting of allow-compression to also refuse framing.
This is important for our DCO implementation as these do not implement framing.
This behaviour surfaced when a commercial VPN provider was pushing
"comp-lzo no" to a client with DCO. While we are technically at fault here
The previous commit (e86bc8b2967) breaks compilation if all compression
algorithms are disabled (--disable-lz4 --disable-lzo). A later patch
in the series would fix this but can not be merged yet.
Signed-off-by: Gert Doering
---
src/openvpn/options.c | 2 ++
1 file changed, 2 insertions(+)
Hi,
On Thu, Mar 23, 2023 at 06:06:00PM +0100, Arne Schwabe wrote:
> index 435e1ca9e..92f7456a4 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -3644,10 +3644,16 @@ options_set_backwards_compatible_options(struct
> options *o)
> *
> * Disable compression by
14 matches
Mail list logo
