Am 14.02.21 um 16:19 schrieb Gert Doering:
> Your patch has been applied to the master branch.
>
> I'm not sure I understand the code, though. It receives the new timeout
> from the server (that is easy), but then caps it by "hand_window", which
> is never increased - so the maximum timeout stays at "60", unless increased
hm max_timeout is maximum of handshake_window and
renegotiate_seconds/2, so max(60,1800) in a default configuration.
> manually on the client. Where am I misreading this? Or is this a
> prerequisite for this functionality?
>
> c->c2.push_request_timeout = ks->established + min_uint(max_timeout,
> server_timeout);
And here we normally take a minimum of 1800 and whatever the server pushed.
> (or am I totally misunderstanding push_request_timeout, and this has
> nothing to do with hand-window, except "it's using this as a default
> value", but only for triggering re-sends, not for "final give up"?)
This patch also splits two timeouts that before just happend to be
identical into two distinct timeouts. One time is the one that says how
TLS (re)negotiation is allowed to be (handshake_window) and the other
one is the pull timeout. The if condition in push.c shows their
relationship:
if (c->c2.push_request_timeout > now
&& (now - ks->peer_last_packet) < c->options.handshake_window)
Basically give the user "max_timeout" time to answer the 2FA challenge
but only if the server has been alive in the last handshake_window seconds.
> However, for my standard test cases, this does not break anything, and
> the code looks reasonable. So in it goes :)
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
