Opened 7 years ago

Last modified 17 months ago

#128 assigned Bug / Defect

Connection errors / comp-lzo only working after reconnect

Reported by: greenITea Owned by:
Priority: minor Milestone: release 2.3.14
Component: Configuration Version:
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: comp-lzo
Cc: Steffan Karger


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.

Change History (21)

comment:1 Changed 7 years ago by David Sommerseth

Keywords: comp-lzo added
Priority: majorminor
Type: Bug / DefectFeature Wish
Version: 2.2.0

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"

              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.

comment:2 Changed 7 years ago by greenITea

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

comment:3 Changed 7 years ago by JJK

Type: Feature WishBug / Defect

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.

comment:4 Changed 7 years ago by David Sommerseth

Component: NetworkingConfiguration
Milestone: release 2.2.1
Owner: set to David Sommerseth
Severity: Not set (if unsure, select this one)Patch Queue: New / awaiting ACK
Status: newaccepted

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.

comment:5 Changed 7 years ago by David Sommerseth

Severity: Patch Queue: New / awaiting ACKNot set (if unsure, select this one)

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.

comment:6 Changed 7 years ago by David Sommerseth

Milestone: release 2.2.1release 2.3

comment:7 Changed 5 years ago by David Sommerseth

Milestone: release 2.3

comment:8 Changed 5 years ago by 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?

comment:9 Changed 4 years ago by 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.

comment:10 Changed 4 years ago by 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

comment:11 Changed 4 years ago by Gert Döring

Milestone: release 2.3.4

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.

comment:12 Changed 4 years ago by Gert Döring

Milestone: release 2.3.4release 2.3.5

Dear ticket owner, can we manage 2.3.5?

comment:13 Changed 3 years ago by David Sommerseth

Owner: David Sommerseth deleted
Status: acceptedassigned

comment:14 Changed 3 years ago by Gert Döring

Milestone: release 2.3.5release 2.3.7

comment:15 Changed 3 years ago by 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'

comment:16 Changed 3 years ago by 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 :-)

comment:17 Changed 3 years ago by Gert Döring

Summary: Connection errorsConnection errors / comp-lzo only working after reconnect

comment:18 Changed 3 years ago by Gert Döring

Milestone: release 2.3.7release 2.3.8

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

comment:19 Changed 3 years ago by Gert Döring

Milestone: release 2.3.8release 2.3.9

comment:20 Changed 23 months ago by Samuli Seppänen

Milestone: release 2.3.9release 2.3.12

comment:21 Changed 17 months ago by Gert Döring

Cc: Steffan Karger added
Milestone: release 2.3.12release 2.3.14

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

Note: See TracTickets for help on using tickets.