Connection errors / comp-lzo only working after reconnect

[greenITea]

This is a well known and long-term bug in OpenVPN

After establishing of the connection you'll get error:
"write to TUN/TAP : Invalid argument (code=22)".
The reason for the error is, that the client do not adapt the "pushed" option 'comp-lzo'.
After restart, because of inactivity timeout, the connection works.

The workaround is putting this option into the client configuration file.

[David Sommerseth]

I'm not sure I'm willing to call this a bug, as it is well explained in the man page:

       --comp-lzo [mode]
              Use  fast LZO compression -- may add up to 1 byte per packet for
              incompressible data.  mode may be  "yes",  "no",  or  "adaptive"
              (default).

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

              First, make sure the client-side config file  enables  selective
              compression by having at least one --comp-lzo directive, such as
              --comp-lzo no.  This will turn off compression by  default,  but
              allow  a  future  directive  push from the server to dynamically
              change the on/off/adaptive setting.

              Next in a --client-config-dir file, specify the compression set‐
              ting for the client, for example:

                  comp-lzo yes
                  push "comp-lzo yes"

              The  first line sets the comp-lzo setting for the server side of
              the link, the second sets the client side.

Please notice the third paragraph.

It might not be how you expect OpenVPN to behave. But it is well described how this feature is working and needs to be configured.

[greenITea]

Maybe I misunderstood the manual page. But why it works after reconnect?

[JJK]

this is a bug: the server pushes out 'comp-lzo' to the client but this is not picked up, because the client does not have 'comp-lzo' configured in the client config (all according to man page). The bug is , that when the client reconnects that it then does honor the 'comp-lzo' pushed out from the server. The client should either consistently refuse 'comp-lzo' or it should consistently accept this option as pushed out by the server.

[David Sommerseth]

I agree with janjust. I overlooked the detail about reconnect. This is a bug.

I've submitted a patch for review which makes '--comp-lzo no' the default behaviour on the client side. This makes 'comp-lzo' all together pushable from server to clients, even if '--comp-lzo' is not defined in the client config.

The old behaviour ('comp-lzo' not pushable) is achievable when doing '--comp-lzo disabled' in the client configs.

​http://thread.gmane.org/gmane.network.openvpn.devel/4650

[David Sommerseth]

It turns out after some testing that the proposed patch causes more troubles than a real solution, which means that we need a different fix for this.

I'm looking into a better fix.

[Samuli Seppänen]

What is the current status of this issue? Do the recent protocol negotiation changes have any potential for solving this issue in a clean way?

[David Sommerseth]

This needs to be re-tested with the new code paths which added snappy support. There's some new methods figuring out this.

[Gert Döring]

needs re-testing

2.4/master has snappy and the new compression framework, and new code, so it might just work out of the box

2.3 has the old code, so it might be still bug

[Gert Döring]

This is not actually hard, but takes time - testing with 2.3, testing with 2.4 - and it's not actually a critical fix. So I'm putting this on the 2.3.4 milestone.

[Gert Döring]

Dear ticket owner, can we manage 2.3.5?

[NashBlade]

For those who find this ticket while researching this error on OpenWRT, the solution is setting the comp_lzo option, rather than comp-lzo (underscore rather than hyphen). E.g.

option comp_lzo 'adaptive'

[Gert Döring]

Well, this format very much looks like "the config file format used by OpenWRT", but it is not genuine OpenVPN option. OpenWRT start scripts translate these options into the native OpenVPN options - and that one is:

--comp-lzo adaptive

(see "man openvpn"). Just to avoid even more confusion :-)

[Gert Döring]

bouncing to 2.3.8 - not forgotten, but we want to get 2.3.7 out and this needs more time

[Gert Döring]

This is the same "options are cached for a while" thing as with --cipher on server reconnects...

[Gert Döring]

We rediscovered this bug and it's now #1396

The underlying bug is "we save some options before connecting to a server, and on a SIGUSR1 restart, only those options get restored, and for the other options, the previously-pushed options go into effect". We've fixed this for some options when doing NCP (cipher), and for others recently (commit 7064ccb9f and 5a2ed714d14a), but during that, we noticed that compress also is not saved/restored properly.

In 2.4+ the effect is different (if you reconnect and then end up on a server that does not push compression, the client will stick to the previously-pushed compression settings), but effectively the same bug.

In the "compression is not actually pushable" times, it worked the other way round... the push only stuck on the next connection.

I am closing this ticket now. It will be fixed for 2.5 and later via #1396. Maybe backported to 2.4, depending on how intrusive the end result looks like. Not to 2.3.