Hi,
Arne and I discussed PUSH_REQUEST/PUSH_REPLY handling in OpenVPN
a lot recently, and found something interesting.
Naively, one would assume that only "--client" (or "--pull") instances
would send PULL_REQUEST messages, and only "--server" (or "--mode server")
instances would reply to them,
Acked-by: Gert Doering
This is magic :-) - it's just a one liner (plus lots of documentation)
but the description makes sense, staring at the code for a while also
makes sense. Plus, it works :-)
I have not tested the server side, as (to my understanding) this is
basically "client side only" c
Am 26.07.20 um 01:51 schrieb Arne Schwabe:
> When a server sends a client a push request, the client will reply
> with a push reply. The reply is bogus and almost empty since almost
> all the options that are normally set (remote ip etc) are unset.
>
> I checked 2.4 and master and this does not ha
Acked-by: Gert Doering
The change to "check_connection_established(c)" is really trivial and
straight-forward, and best viewed with "git show -w". Taking away
an effective no-op wrapper function and getting rid of one indentation
level is always good.
Nevertheless I've forced this through the f
Hi,
On Sun, Jul 26, 2020 at 04:19:21PM +0200, Arne Schwabe wrote:
> Am 26.07.20 um 15:40 schrieb Gert Doering:
> > I wonder if we could just skip print the error message for this
> > particular call (connect()) if the return is EBUSY? Or maybe
> > "skip if utunnumber < 10 && EBUSY"?
>
> since yo
Am 26.07.20 um 15:40 schrieb Gert Doering:
> Acked-by: Gert Doering
>
> I've left out the stray uncrustify fixes - not that I disagree with
> them, but they should go to their own patch. Sorry for not cleaning
> that up while merging the corresponding patch.
>
> Code change looks good. Not tes
Acked-by: Gert Doering
I've left out the stray uncrustify fixes - not that I disagree with
them, but they should go to their own patch. Sorry for not cleaning
that up while merging the corresponding patch.
Code change looks good. Not tested anything (only test compiled on MacOS).
I wonder if
Am 26.07.20 um 02:01 schrieb Arne Schwabe:
> Am 17.07.20 um 19:10 schrieb David Sommerseth:
>> The --no-replay feature is considered to be a security weakness, which
>> was also highlighed during the OpenVPN 2.4 security audit [0]. This
>> option was added to the DeprecatedOptions[1] list and has
a little help..
On 26/07/2020 00:48, Arne Schwabe wrote:
The introduction of IV_PROTO_REQUEST_PUSH (c290df55) sometimes causes the
server to reply before we setup the push timer. The push reply will then clear
a timer that has not been setup yet. We then start sending push
request after we have
Sanity check:
On 26/07/2020 00:51, Arne Schwabe wrote:
When a server sends a client a push request, the client will reply
with a push reply. The reply is bogus and almost empty since almost
all the options that are normally set (remote ip etc) are unset.
I checked 2.4 and master and this does n
10 matches
Mail list logo
