diff mbox series

[Openvpn-devel,1/1] Exit management interface loop early on receiving 'remote MOD' message.

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

Commit Message

Daniel Kaldor July 3, 2019, 4:50 a.m. UTC 
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(-)

                 man_check_for_signals(&signal_received);
--
2.9.3 (Apple Git-75)

Comments

Arne Schwabe Oct. 1, 2020, 2:23 a.m. UTC | #1 
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
Gert Doering Jan. 23, 2021, 2:56 a.m. UTC | #2 
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 mbox series

Patch

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)
             {