Hi,
On Thu, Sep 10, 2020 at 12:19 AM Marvin wrote:
> Hi Selva,
>
> The GUI did not have this error unless run as administrator which you
>> should not and will never work.
>
> So you are saying that if OpenVPN is installed by a user who has admin
> privileges (as our case does) that v2.5 with wi
Hi Selva,
The GUI did not have this error unless run as administrator which you
> should not and will never work.
So you are saying that if OpenVPN is installed by a user who has admin
privileges (as our case does) that v2.5 with wintun will not work?
On Wed, Sep 9, 2020 at 6:03 PM Selva Nair w
Hi
On Wed, Sep 9, 2020 at 8:30 PM Marvin wrote:
> Selva,
>
> Sorry for the wrong thread. I was replying to an earlier thread about
> this same error on Beta1 and beta2. So i am a bit confused by your
> statement that this error did not show up in earlier betas, because that's
> what started th
Selva,
Sorry for the wrong thread. I was replying to an earlier thread about this
same error on Beta1 and beta2. So i am a bit confused by your statement
that this error did not show up in earlier betas, because that's what
started this thread.
Marvin
On Wed, Sep 9, 2020 at 5:14 PM Selva Nair
Hi Marvin,
This is the wrong thread, but...
On Wed, Sep 9, 2020 at 7:54 PM Marvin wrote:
> Hi Guys,
>
> I just tested beta3 on Win10. I am getting the exact same error with
> wintun as before. TAP works normally. I tried with the GUI and by cli.
>
The GUI never generated this error even bef
Hi Guys,
I just tested beta3 on Win10. I am getting the exact same error with
wintun as before. TAP works normally. I tried with the GUI and by cli.
2020-09-09 16:23:20 us=991306 ERROR: Wintun requires SYSTEM privileges and
therefore should be used with interactive service. If you want to use
From: Selva Nair
trac #1059
Signed-off-by: Selva Nair
---
doc/man-sections/generic-options.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/doc/man-sections/generic-options.rst
b/doc/man-sections/generic-options.rst
index a07fe7e..d5f0883 100644
--- a/doc/man-sections/generic-op
Ok, thank you for clarification
--
Best Regards, Vladislav Grishenko
> -Original Message-
> From: David Sommerseth
> Sent: Wednesday, September 9, 2020 10:49 PM
> To: Vladislav Grishenko ; openvpn-
> de...@lists.sourceforge.net
> Subject: Re: [Openvpn-devel] [PATCH] Fix --remote protocol
The --remote entry had a syntax mistake in the argument examples, which
was introduced during the .rst conversion.
In addition this section did not have a good flow. So the text was
regrouped and re-organized a bit so related text pieces are now gathered
in the same context instead of being more
On 09/09/2020 11:21, Arne Schwabe wrote:
Am 09.09.20 um 10:04 schrieb François Kooman:
On 9/8/20 6:38 PM, Arne Schwabe wrote:
I really wonder which large deployment want to do that instead of a CA.
I really understand the need for small and simple deployments. But for
larger deployments a CA
On 08/09/2020 21:01, Vladislav Grishenko wrote:
> Hi David,
>
>> -Original Message-
>> From: David Sommerseth
>> Sent: Tuesday, September 8, 2020 6:23 PM
>> To: Vladislav Grishenko ; openvpn-
>> de...@lists.sourceforge.net
>> Subject: Re: [Openvpn-devel] [PATCH] Fix --remote protocol can'
Our code works on "very old Linux" (Fedora-1), but needs a #define
for TUNSETGROUP to compile. Everything else is there.
While at it, fix TUNSETGROUP error message.
Reported-By: noloader on Trac
Trac: #1152
Signed-off-by: Gert Doering
---
src/openvpn/tun.c | 7 ++-
1 file changed, 6 inser
> From: Arne Schwabe
> Sent: Wednesday, September 9, 2020 5:15 PM
> > I see your point, thank you.
> > Fallback is done just to conform RFC 2782 suggestion, personally I feel it's
> hardly be used with controllable client profiles when it's known that
> domain.tld
> does dns srv.
>
> Yes. And see
"echo -n" is inherently less portable than printf, so the tests look
ugly on (at least) OpenSolaris/Illumos on AIX.
Add a blank at the end of the tls-crypt-v2 messages, so it has the
same look as the cipher messages ("... OK").
Reported-by: mnowak on Trac
Trac: #1196
Signed-off-by: Gert Doering
The man page claimed that --client-disconnect "is passed the same
pathname as the corresponding --client-connect command", which is
not what the code does. Fix.
Reported-By: hvenev in Trac
Trac: #884
Signed-off-by: Gert Doering
---
doc/man-sections/script-options.rst | 5 ++---
1 file changed,
When a SOCKS5 server sends back a reply, it encodes an "address",
which can be IPv4 (4 bytes), IPv6 (16 bytes) or "a domain name",
which has a lenght (1 byte) and "a string of length " - so
when copying bytes, we need to hande "length +1" bytes.
Our code totally doesn't use this variant of address
> I see your point, thank you.
> Fallback is done just to conform RFC 2782 suggestion, personally I feel it's
> hardly be used with controllable client profiles when it's known that
> domain.tld does dns srv.
Yes. And see the point in that RFC. I would rather document that for out
fallback the u
When a SOCKS5 server sends back a reply, it encodes an "address",
which can be IPv4 (4 bytes), IPv6 (16 bytes) or "a domain name",
which has a lenght (1 byte) and "a string of length " - so
when copying bytes, we need to hande "length +1" bytes.
Our code totally doesn't use this variant of address
When a SOCKS5 server sends back a reply, it encodes an "address",
which can be IPv4 (4 bytes), IPv6 (16 bytes) or "a domain name",
which has a lenght (1 byte) and "a string of length " - so
when copying bytes, we need to hande "length +1" bytes.
Our code totally doesn't use this variant of address
Hi, Arne
> From: Arne Schwabe
> Sent: Wednesday, September 9, 2020 4:29 PM
> Am 26.08.20 um 18:51 schrieb Vladislav Grishenko:
> > DNS SRV host discovery allows to have multiple OpenVPN servers for a
> > single domain w/o explicit profile enumeration, to move services from
> > host to host with li
Am 26.08.20 um 18:51 schrieb Vladislav Grishenko:
> DNS SRV host discovery allows to have multiple OpenVPN servers for a single
> domain w/o explicit profile enumeration, to move services from host to host
> with little fuss, and to designate hosts as primary servers for a service
> and others as b
This is basic housekeeping, adding NULL checks to context initialization
of the sample plugin collection which are missing it. Realistically,
this can never happen, but since these are supposed to be "good examples",
not checking calloc() return isn't one.
Trac: #587
Reported-By: Dogbert (in Tra
Am 09.09.20 um 10:04 schrieb François Kooman:
> On 9/8/20 6:38 PM, Arne Schwabe wrote:
>> I really wonder which large deployment want to do that instead of a CA.
>> I really understand the need for small and simple deployments. But for
>> larger deployments a CA + CRL seems more useful for everythi
On 9/8/20 6:38 PM, Arne Schwabe wrote:
I really wonder which large deployment want to do that instead of a CA.
I really understand the need for small and simple deployments. But for
larger deployments a CA + CRL seems more useful for everything that I
can come up with.
It would be more for the
Patch has been applied to the master, release/2.5 and release/2.4 branch.
The 2.4 patch only has the actual "--inetd" fix, not the uncrustify whitespace
change for --bind-dev (code not in 2.4).
(As a side note for the protocol: it turns out this only fixes "--inetd nowait",
aka "--proto tcp-serve
25 matches
Mail list logo
