Opened 7 years ago

Last modified 14 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: syzzer

Description

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 dazo

  • Keywords comp-lzo added
  • Priority changed from major to minor
  • Type changed from Bug / Defect to Feature Wish
  • Version 2.2.0 deleted

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.

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 janjust

  • Type changed from Feature Wish to Bug / 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 dazo

  • Component changed from Networking to Configuration
  • Milestone set to release 2.2.1
  • Owner set to dazo
  • Severity changed from Not set (if unsure, select this one) to Patch Queue: New / awaiting ACK
  • Status changed from new to accepted

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

comment:5 Changed 7 years ago by dazo

  • Severity changed from Patch Queue: New / awaiting ACK to Not 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 dazo

  • Milestone changed from release 2.2.1 to release 2.3

comment:7 Changed 5 years ago by dazo

  • Milestone release 2.3 deleted

comment:8 Changed 4 years ago by samuli

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 dazo

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 cron2

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 cron2

  • Milestone set to 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 cron2

  • Milestone changed from release 2.3.4 to release 2.3.5

Dear ticket owner, can we manage 2.3.5?

comment:13 Changed 3 years ago by dazo

  • Owner dazo deleted
  • Status changed from accepted to assigned

comment:14 Changed 3 years ago by cron2

  • Milestone changed from release 2.3.5 to release 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 cron2

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 cron2

  • Summary changed from Connection errors to Connection errors / comp-lzo only working after reconnect

comment:18 Changed 3 years ago by cron2

  • Milestone changed from release 2.3.7 to release 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 2 years ago by cron2

  • Milestone changed from release 2.3.8 to release 2.3.9

comment:20 Changed 20 months ago by samuli

  • Milestone changed from release 2.3.9 to release 2.3.12

comment:21 Changed 14 months ago by cron2

  • Cc syzzer added
  • Milestone changed from release 2.3.12 to release 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.