Message ID | CAL3L06F7YvNHSFxWXrMFZf_8fSjmCH-RkMn1GXmLu7cW-G1=nw@mail.gmail.com |
---|---|
State | Deferred |
Headers | show |
Series | [Openvpn-devel,1/1] Exit management interface loop early on receiving 'remote MOD' message. | expand |
Am 03.07.19 um 16:50 schrieb Daniel Kaldor: > OpenVPN using management interface and running with > 'management-query-remote' in the config will wait for a 'remote MOD' > or 'remote ACCEPT' message before continuing with connection. > > Logs indicate that this stage of the connection process currently > takes ~1s to complete. > This seems to be because the management interface polling loop is > being run once unnecessarily after receiving 'remote MOD' message, and > is only exiting after 1s timeout is reached on final polling loop. > > This change exits the polling loop early, immediately after receiving > 'remote MOD' message and removes 1s delay in connection. > > > --- > src/openvpn/manage.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c > index 2d86dad..7343e8b 100644 > --- a/src/openvpn/manage.c > +++ b/src/openvpn/manage.c > @@ -3348,7 +3348,13 @@ management_event_loop_n_seconds(struct > management *man, int sec) > /* run command processing event loop */ > do > { > - man_standalone_event_loop(man, &signal_received, expire); > + int status = -1; > + > + status = man_standalone_event_loop(man, &signal_received, expire); > + if (status > 0) > + { > + return; > + } > if (!signal_received) > { > man_check_for_signals(&signal_received); I have no doubt that the patch fixes your particular problem but it modifies the management loop to exit early for all commands and this feels it could cause trouble for other commands. Did you test anything other your use case? Arne
Hi, On Wed, Jul 03, 2019 at 03:50:41PM +0100, Daniel Kaldor wrote: > OpenVPN using management interface and running with > 'management-query-remote' in the config will wait for a 'remote MOD' > or 'remote ACCEPT' message before continuing with connection. > > Logs indicate that this stage of the connection process currently > takes ~1s to complete. > This seems to be because the management interface polling loop is > being run once unnecessarily after receiving 'remote MOD' message, and > is only exiting after 1s timeout is reached on final polling loop. > > This change exits the polling loop early, immediately after receiving > 'remote MOD' message and removes 1s delay in connection. This might actually have been fixed by commit d08b66f39cf80733a51e1607386dc4993faef09f Author: Vladislav Grishenko <themiron@yandex-team.ru> Date: Fri Oct 2 03:53:19 2020 +0500 Speedup TCP remote hosts connections For non-blocking TCP/Unix connection, OpenVPN checks was it established in loop and if not - sleeps or handles management for next one second. Since the first check is made right after the connection attempt, it will likely be always unsuccessful, causing redundant wait for one or more seconds: ... v3: teach management_sleep() to handle zero timeout and reject negative use 1s timeout for connection and 0s timeout for management events could you check if this solves the delays you are experiencing as well? If not, please re-send, taking Arne's comments into account. gert
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c index 2d86dad..7343e8b 100644 --- a/src/openvpn/manage.c +++ b/src/openvpn/manage.c @@ -3348,7 +3348,13 @@ management_event_loop_n_seconds(struct management *man, int sec) /* run command processing event loop */ do { - man_standalone_event_loop(man, &signal_received, expire); + int status = -1; + + status = man_standalone_event_loop(man, &signal_received, expire); + if (status > 0) + { + return; + } if (!signal_received) {