Page 1 of 1

Bad LZO decompression header byte: 69

Posted: Tue Feb 23, 2016 8:45 pm
by Kulturmensch
After successful OpenVPN-connection between IPhone 6 (iOS 9.2) and my root server (Ubuntu LTS 14.04.3) I find the following error message in the server“s openvpn logfile:

Bad LZO decompression header byte: 69

I can also not open Internetpages on the IPhone if the connection via tunnel is enabled.

Concerning compression it is possible to choose (OpenVPN IPhone) one of these 3 options:
  • No
  • Full
  • Downlink only
.

In the config files on either the client (IPhone) and server side I used; comp-lzo

Any idea how to fix this?

Re: Bad LZO decompression header byte: 69

Posted: Tue Feb 23, 2016 9:30 pm
by Kulturmensch
I could fix it and everything works now with the Apple-World, too.

Re: Bad LZO decompression header byte: 69

Posted: Tue Feb 23, 2016 10:48 pm
by Pippin
It would be nice if you share your solution :idea:

Re: Bad LZO decompression header byte: 69

Posted: Wed Feb 24, 2016 12:03 am
by Traffic
My guess would be --comp-lzo no (both sides)

FYI, in the server conf or CCD file this is permitted:

Code: Select all

push "comp-lzo parameter"
      comp-lzo parameter
which configures both server and client globally or on a specific connection (at this time)
With the caveat that at least:

Code: Select all

comp-lzo
is used in both server and client confs. (To initialize the LZO function)

LZ4 is soon to hit the frame as well .. that should be fun !
Snappy got binned ..

Re: Bad LZO decompression header byte: 69

Posted: Thu Feb 25, 2016 7:57 pm
by Kulturmensch
Sorry for the late reply, I do not receive notifications and have manually to check replies.

Here we are with my working configuration

root server (Linux) <-> Iphone/IPad

I configured both server and client globally with
comp-lzo
and selected for the IPhone/IPad client the following in the APP-configuration:
Raise keyboard on
Seamless tunnel on
Connect via Any network
Reconnect on wakeup on
Protocol UDP
Compression FULL
Connection Timeout 30 seconds
Network state detection active
Advanced Settings
Force AES-CBS-ciphersuites on
Google DNS fallback on
Layer 2 reachability off

No proxy

client conf (which was installed using I-Tunes):
client
remote server.ip port
proto udp
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher AES-256-CBC
comp-lzo
verb 3
--tls-auth ta.key 1
key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
....
....
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
....
....
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
....
....
-----END PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
....
....
-----END OpenVPN Static key V1-----
</tls-auth>

Hope, this helps :)

Re: Bad LZO decompression header byte: 69

Posted: Thu Feb 25, 2016 8:16 pm
by Kulturmensch
I just learned that client should be replaced by tls-client
Thanks to Pippin

Re: Bad LZO decompression header byte: 69

Posted: Thu Feb 25, 2016 8:52 pm
by Kulturmensch
and --tls-auth ta.key 1 can be deleted, it is redundant in my example.

Re: Bad LZO decompression header byte: 69

Posted: Sat Feb 27, 2016 10:31 am
by Traffic
Kulturmensch wrote:I just learned that client should be replaced by tls-client
Thanks to Pippin
--client should not be replaced by --tls-client

--client expands to --tls-client & --pull

--tls-client does not expand and so you loose --pull

Re: Bad LZO decompression header byte: 69

Posted: Sat Feb 27, 2016 10:45 am
by Pippin
Yup, i stand corrected :)

Re: Bad LZO decompression header byte: 69

Posted: Sat Feb 27, 2016 6:55 pm
by Kulturmensch
Oh, that explains my fault by using tls-client.
Thank you:-)