Opened 13 years ago

Closed 3 years ago

#128 closed Bug / Defect (fixed-external)

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 (22)

comment:1 Changed 13 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 13 years ago by greenITea

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

comment:3 Changed 13 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 13 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 13 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 13 years ago by David Sommerseth

Milestone: release 2.2.1release 2.3

comment:7 Changed 11 years ago by David Sommerseth

Milestone: release 2.3

comment:8 Changed 11 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 11 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 11 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 10 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 10 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 9 years ago by David Sommerseth

Owner: David Sommerseth deleted
Status: acceptedassigned

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

Milestone: release 2.3.5release 2.3.7

comment:15 Changed 9 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 9 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 9 years ago by Gert Döring

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

comment:18 Changed 9 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 9 years ago by Gert Döring

Milestone: release 2.3.8release 2.3.9

comment:20 Changed 8 years ago by Samuli Seppänen

Milestone: release 2.3.9release 2.3.12

comment:21 Changed 8 years 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...

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

Resolution: fixed-external
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.