Hi,
Thanks for the changes. Looks good.
On Tue, May 3, 2022 at 9:12 AM Lev Stipakov wrote:
> From: Lev Stipakov
>
> We use M_ERRNO flag in logging to display error code
> and error message. This has been broken on Windows,
> where we use error code from GetLastError() and
> error description f
Acked-By: Frank Lichtenheld
Trivial code move. Compiles now.
> Arne Schwabe hat am 03.05.2022 13:29 geschrieben:
>
>
> This makes the tls_process_state function a bit easier to read allows
I still think there is an "and" missing after "read"
> extending the read_incoming_tls_plaintext func
From: Lev Stipakov
We use M_ERRNO flag in logging to display error code
and error message. This has been broken on Windows,
where we use error code from GetLastError() and
error description from strerror(). strerror() expects
C runtime error code, which is quite different from
last error code fro
Hi,
Also there are some places openvpn_errno() is used and the result checked
> against POSIX error codes:
> in forward.c around line 2102:
>
> if ( && ENETUNREACH == error_code && ...)
>
> where error_code = openvpn_errno() which may return WSAENETUNREACH on
> Windows not ENETUNREACH-- even t
This makes the tls_process_state function a bit easier to read allows
extending the read_incoming_tls_plaintext function later without
making tls_process_state even longer.
Patch v2: fix compile error.
Signed-off-by: Arne Schwabe
---
src/openvpn/ssl.c | 42 +++---
NACK, compile error.
> Arne Schwabe hat am 22.04.2022 16:29 geschrieben:
>
>
> This makes the tls_process_state function a bit easier to read allows
missing "and" after read?
> extending the read_incoming_tls_plaintext function later without
> making tls_process_state even longer.
> ---
> s
Acked-By: Frank Lichtenheld
Change makes sense to me, only some commit message/comment
suggestions.
Still applies on top of 18 v3 + 22 v3 (with git am -3).
Compile/UT tested only.
> Arne Schwabe hat am 22.04.2022 16:29 geschrieben:
> We move to the S_START when we have finished the three-way ha
Still found a few typos and whitespace issues, but no code issues.
Overall this looks okay to me but I'm hesitant to actually ack it
because I'm not sure of the potential implications of all the protocol
hacks (i.e. the packet id flags and the TLV payload).
> Arne Schwabe hat am 02.05.2022 18:09
Acked-By: Frank Lichtenheld
Used this patch to make myself familiar with the OpenVPN RFC documentation
enough to say that this change overall makes sense to me. No further
issues found in the code. Just some more text/whitespace issues, see below.
Compile/UT tested only from my side.
Small issu
