OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Packages
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version openwrt-18.06
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 1
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by FREDY - 30.10.2018
Last edited by Mathias Kresin - 12.11.2018

FS#1919 - comp_lzo doesn't work on OpenVPN in TP-Link C20 (AC750) v4

- Device problem occurs on
TP-LINK C20 (AC750) v4

- Software versions of OpenWrt/LEDE release, packages, etc.
OpenWrt 18.06.1 r7258-5eb055306f
Kernel 4.14.63
OpenVPN 2.4.5 mipsel-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
library versions: OpenSSL 1.0.2p 14 Aug 2018, LZO 2.10

- Steps to reproduce
Configure 2 sides using the uci format (exemple below) using the “option comp_lzo yes” and they will not connect or pass any traffic. When this option is removed it then connects

I have installed this version of OpenWrt on this hardware and tried to bring up a P2P OpenVPN as done before with other OpenWrt routers (other versions of hardware and OpenWrt). After a lot of troubleshooting I found that when running it with “option comp_lzo yes” it never works.

In one of the troubleshoots I have done I have used this configuration at both sides:

Server


config openvpn myvpn

      option port 1194
      option proto udp
      option dev tun0
      option keepalive "10 60"
      option persist_key 1
      option persist_tun 1
      option cipher AES-128-CBC
      option secret /etc/config/mykey.key
      option ifconfig "10.0.0.1 10.0.0.2"
      list route "192.168.1.0 255.255.255.0"
      list push "redirect-gateway def1"
      option comp_lzo yes
      option enabled 1

Client


/usr/sbin/openvpn –remote myhostname.zapto.org –proto udp –port 1194 –dev tun0 –cipher AES-128-CBC –secret /root/mykey.key –keepalive 10 60 –ping-timer-rem –persist-tun –persist-key –ifconfig 10.0.0.2 10.0.0.1 –route 192.168.2.0 255.255.255.0 10.0.0.21 –comp-lzo –push redirect-gateway def1 –script-security 2

RESULTS


- I get the following on the client side:

Tue Oct 30 03:50:54 2018 Bad LZO decompression header byte: 69
Tue Oct 30 03:50:55 2018 Bad LZO decompression header byte: 69
Tue Oct 30 03:50:56 2018 Bad LZO decompression header byte: 69
Tue Oct 30 03:50:56 2018 Bad LZO decompression header byte: 40

Software Versions


- I have been using in this way between several routers and versions of OpenWrt and never had such problem, only in 18.06.1 and in TP-Link C20 v4. Find below the version of software in each of the routers for comparison:

This Router (doesn’t work) - TP-Link C20 v4 → library versions: OpenSSL 1.0.2p 14 Aug 2018, LZO 2.10
Router 2 (works)- Debian 8, armv7l, Kernel 3.4.39 → library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.08
Router 3 (works) - Debian 7.9, armv6l, 4.1.13+ → library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Router 4 (works) - TP-Link TL-WDR3600 v1, LEDE 17.01.4, r3560-79f57e422d, mips, Kernel 4.4.92 → library versions: OpenSSL 1.0.2n 7 Dec 2017, LZO 2.10
Router 5 (works) - TP-Link TL-WDR3600 v1, OpenWrt Chaos Calmer 15.05.1, mips, Kernel 3.18.23 → library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08

*works - between all of them, except with the TP-Link C20 v4 running 18.06.1

Another test running directly in command line


- I have done an ad-hoc test running in the command line and it seemed to work. It was between this router and a Windows 10 Machine. However when running using the UCI configuration it gives me the LZO decompression header problem. See below the two configuration

Server side (this router)


/usr/sbin/openvpn –proto udp –lport 1400 –dev tun10 –cipher AES-128-CBC –secret /root/mykey.key –keepalive 10 60 –ping-timer-rem –persist-tun –persist-key –ifconfig 192.168.14.1 192.168.14.2 –comp-lzo –push “redirect-gateway def1”

Client Side (Windows 10)


proto udp
dev tun
remote myhostname.zapto.org
port 1400
cipher AES-128-CBC
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
comp-lzo
tun-mtu 1500
mssfix 1300
ifconfig 192.168.14.2 192.168.14.1

<secret>
mykey
</secret>

Now using the UCI OpenWrt configuration (same Client configuration above)


Server


config openvpn remote

      option enabled 1
      option port 1400
      option proto udp
      option dev tun10
      option keepalive "10 60"
      option persist_key 1
      option persist_tun 1
      option cipher AES-128-CBC
      option secret /etc/config/mykey.key
      option ifconfig "192.168.14.1 192.168.14.2"
      list push "redirect-gateway def1"

Result


Tue Oct 30 10:53:38 2018 Bad LZO decompression header byte: 42
Tue Oct 30 10:53:48 2018 Bad LZO decompression header byte: 42
Tue Oct 30 10:53:58 2018 Bad LZO decompression header byte: 42


Closed by  Mathias Kresin
12.11.2018 19:36
Reason for closing:  Duplicate
Additional comments about closing:  

Duplicate of FS#1478

FREDY commented on 31.10.2018 21:28

An update about this: I have been reading some discussions about this issue in other OpenVPN forums and was wondering that as it works on OpenWrt when I run the command line directly that maybe the configuration "option comp_lzo yes" is not being honoured correctly when OpenWrt turns that into a OpenVPN standard configuration.

In order to double check that I made a temporary server config as follwoing:

config openvpn test

      option enabled 1
      option port 1400
      option proto udp
      option dev tun10
      option keepalive "10 60"
      option persist_key 1
      option persist_tun 1
      option cipher AES-128-CBC
      option secret /etc/config/mykey.key
      option ifconfig "192.168.14.1 192.168.14.2"
      option comp_lzo yes
      list push "redirect-gateway def1"

And checked the generated opevpn-test.conf file in /tmp/etc and the content was:

persist-key
persist-tun
cipher AES-128-CBC
comp-lzo yes

dev tun10
ifconfig 192.168.14.1 192.168.14.2
keepalive 10 60
port 1400
proto udp
push "redirect-gateway def1"
secret /etc/config/mykey.key

So as it is possible to see the generated configuration with regards comp-lzo seems not correct and is probably ignored resulting in a OpenVPN server without compression causing that error messagem when trying to communicate with a client with compression enabled. The correct would be only "comp-lzo" and not "comp-lzo yes"

I also tried to change the /etc/config/openvpn to "option comp_lzo" only but then it strips it out of the generated opevpn-test.conf file.
Tried also with "option comp_lzo 1" but then I generates the configuration with "comp-lzo 1" which is also not correct.

Can anyone confirm this ?

FREDY commented on 09.11.2018 15:03

I am closing this task as I found it to be a duplicate of #1478

The reason is that option comp_lzo has been removed from uci due to the fact it has been deprecated in OpenVPN 2.4 and replaced by –compress lzo and –compress lz4 https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#a--comp-lzo

That's the openwrt commit that removed it - https://github.com/openwrt/openwrt/commit/89b8ba96b404d2e412d5573e25348287255671dd#diff-37e75a0201711d64802dc863bc6019f5

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing