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:
.
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

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:
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:-)