Make '--comp-lzo no' the default behaviour if LZO is enabled

This makes 'comp-lzo' pushable without requiring clients to have --comp-lzo defined in the client configs.  To make 'comp-lzo' not pushable on the client, a new 'disabled' argument have been added.

Trac-ticket: 128

Signed-off-by David Sommerseth <[email protected]...>

---
 openvpn.8 |   12 ++++++------
 options.c |   10 +++++++---

 2 files changed, 13 insertions(+), 9 deletions(-)

openvpn.8 +0 -0

index 5cbf4c5..89759b6 100644
@@ -2284,7 +2284,9 @@ limit repetitive logging of similar message types.

 Use fast LZO compression \-\- may add up to 1 byte per packet for incompressible data.
 .B mode

openvpn.8 +3 -1

-may be "yes", "no", or "adaptive" (default).
+may be "yes", "adaptive" or "disabled".
+If  \-\-comp-lzo is used without an argument, it defaults to
+"adaptive".

 In a server mode setup, it is possible to selectively turn compression on or off for individual clients.

openvpn.8 +0 -0

@@ -2293,11 +2295,9 @@ First, make sure the client-side config file enables selective

 compression by having at least one
 .B \-\-comp-lzo
 directive, such as
-.B \-\-comp-lzo no.

openvpn.8 +3 -4

-This will turn off compression by default,
-but allow a future directive push from the server to
-dynamically change the
-on/off/adaptive setting.
+
+If the "disabled" argument is given, \-\-comp-lzo can not be pushed
+from the server to the client.

 Next in a
 .B \-\-client-config-dir

options.c +4 -0

index f643acc..dc45282 100644
@@ -816,6 +816,10 @@ init_options (struct options *o, const bool init_gc)
           o->tmp_dir = "/tmp";
   }
  #endif /* WIN32 */
+
+#ifdef USE_LZO
+  o->lzo = LZO_SELECTED;
+#endif
  }
 

 void

options.c +2 -2

@@ -5889,13 +5893,13 @@ add_option (struct options *options,
        {
          if (streq (p[1], "yes"))
            options->lzo = LZO_SELECTED|LZO_ON;
-         else if (streq (p[1], "no"))
-           options->lzo = LZO_SELECTED;
          else if (streq (p[1], "adaptive"))
            options->lzo = LZO_SELECTED|LZO_ON|LZO_ADAPTIVE;
+         else if (streq (p[1], "disabled"))
+           options->lzo = 0;

         else
           {
-             msg (msglevel, "bad comp-lzo option: %s -- must be 'yes', 'no', or 'adaptive'", p[1]);
+             msg (msglevel, "bad comp-lzo option: %s -- must be 'yes', 'adaptive' or 'disabled", p[1]); goto err;
           }
       }
--
1.7.4.4

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Openvpn-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

This makes 'comp-lzo' pushable without requiring clients to have --comp-lzo defined in the client configs. To make 'comp-lzo' not pushable on the client, a new 'disabled' argument have been added.

Trac-ticket: 128

Signed-off-by David Sommerseth <[email protected]...>

---
 openvpn.8 |   12 ++++++------
 options.c |   10 +++++++---
 2 files changed, 13 insertions(+), 9 deletions(-)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 4 lines · David Sommerseth

This makes 'comp-lzo' pushable without requiring clients to have --comp-lzo defined in the client configs. To make 'comp-lzo' not pushable on the client, a new 'disabled' argument have been added.

Quoted 8 lines

Trac-ticket: 128

Signed-off-by David Sommerseth <[email protected]...>

---
 openvpn.8 |   12 ++++++------
 options.c |   10 +++++++---
 2 files changed, 13 insertions(+), 9 deletions(-)

As announced on the developers meeting yesterday (Samuli will paste the summary with the discussion), I'm withdrawing this patch in the current form.

The reason is that the OpenVPN wire protocol changes slightly when using '--comp-lzo no' versus not having --comp-lzo in the config file. This change will cause server/client incompatibilities.

Alon proposed another approach with white/blacklist of pushed options which should be processed. And this approach do make a lot of sense, and we should implement this as well. But this will be a bigger change.

However, I'm looking at a different approach right now isolated to
- --comp-lzo, where OpenVPN can detect incompatible --comp-lzo settings and rather provide a better error and stop OpenVPN. This I consider better than to try to reconnect indefinitely when critical config options on client and server is incompatible.

- From a quick brain storm, for --comp-lzo, the only compatible/valid combinations are:

   Client                      Server
   (no --comp-lzo)             (no --comp-lzo)
   --comp-lzo {,adaptive} (*)  --comp-lzo {,adaptive}
   --comp-lzo yes         (*)  --comp-lzo yes
   --comp-lzo no          (*)  --comp-lzo no

(*) In these combinations, comp-lzo should be pushable which can change the client setting. If client does not have comp-lzo in its config, it should disconnect from the server if the server pushes --comp-lzo settings, as the wire protocol from the server will be different from what the client expects.

Quoted 9 lines

- From a quick brain storm, for --comp-lzo, the only compatible/valid combinations are:

   Client                      Server
   (no --comp-lzo)             (no --comp-lzo)
   --comp-lzo {,adaptive} (*)  --comp-lzo {,adaptive}
   --comp-lzo yes         (*)  --comp-lzo yes
   --comp-lzo no          (*)  --comp-lzo no

Quoted 7 lines

(*) In these combinations, comp-lzo should be pushable which can change the client setting. If client does not have comp-lzo in its config, it should disconnect from the server if the server pushes --comp-lzo settings, as the wire protocol from the server will be different from what the client expects.

please remember the reason for this patch: bug
https://community.openvpn.net/openvpn/ticket/128

if there is a 'comp-lzo' mismatch and the server pushes out 'push "comp-lzo yes"' then upon reconnecting it works all of a sudden - this inconsistency needs to be addressed one way or the other.
If we don't want to change the 'comp-lzo' behaviour then at the very least this "reconnect-makes-it-work" feature/bug should be fixed in a different manner.