After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 739519 - network-manager-openvpn connects but no internet access.
network-manager-openvpn connects but no internet access.
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: VPN: openvpn
0.9.x
Other Linux
: Normal major
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-11-01 21:43 UTC by Kal
Modified: 2016-05-13 16:43 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
better support comp-lzo setting (7.04 KB, patch)
2016-05-13 15:17 UTC, Thomas Haller 		none Details | Review

Description Kal 2014-11-01 21:43:37 UTC 
When trying to use nm-openvpn with standard config files provided by my vpn supplier I can connect to the vpn
but have no access to the internet. Neither pinging of IP or Hostnames works.

This is in contrast to using openvpn --config in a console. I suspect that nm-openvpn does not set routes correctly. Below are log files
of a working openvpn connect using the console and the syslog output from nm-openvpn. I have also attached the routing table for both instances.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages network-manager-openvpn depends on:
ii  libc6             2.19-12
ii  libdbus-1-3       1.8.8-2
ii  libdbus-glib-1-2  0.102-1
ii  libglib2.0-0      2.42.0-2
ii  libnm-glib-vpn1   0.9.10.0-3
ii  libnm-glib4       0.9.10.0-3
ii  libnm-util2       0.9.10.0-3
ii  openvpn           2.3.2-9

Package: network-manager-openvpn
Version: 0.9.10.0-1

example.ovpn file:

client
dev tun
proto tcp
remote vpn.vpnProvider.com 443
resolv-retry infinite
nobind
persist-key
persist-tun
persist-remote-ip
ca ca.vpnProvider.com.crt
tls-remote vpn.vpnProvider.com
auth-user-pass
comp-lzo
verb 3
auth SHA256
cipher AES-256-CBC
keysize 256
tls-cipher DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA

-------------------------------------------------------------------------------------------------------------------------------------

Working Output from openvpn + Route Table at end:

root@Laptop:/home/user1/vpn# openvpn --config example.ovpn 
Sat Nov  1 01:14:35 2014 DEPRECATED OPTION: --tls-remote, please update your configuration
Sat Nov  1 01:14:35 2014 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Mar 17 2014
Enter Auth Username: *********
Enter Auth Password: **********
Sat Nov  1 01:15:20 2014 Deprecated TLS cipher name 'DHE-RSA-AES256-SHA', please use IANA name 'TLS-DHE-RSA-WITH-AES-256-CBC-SHA'
Sat Nov  1 01:15:20 2014 Deprecated TLS cipher name 'DHE-DSS-AES256-SHA', please use IANA name 'TLS-DHE-DSS-WITH-AES-256-CBC-SHA'
Sat Nov  1 01:15:20 2014 Deprecated TLS cipher name 'AES256-SHA', please use IANA name 'TLS-RSA-WITH-AES-256-CBC-SHA'
Sat Nov  1 01:15:20 2014 Socket Buffers: R=[87380->131072] S=[16384->131072]
Sat Nov  1 01:15:20 2014 Attempting to establish TCP connection with [AF_INET]***.***.85.2:443 [nonblock]
Sat Nov  1 01:15:21 2014 TCP connection established with [AF_INET]***.***.85.2:443
Sat Nov  1 01:15:21 2014 TCPv4_CLIENT link local: [undef]
Sat Nov  1 01:15:21 2014 TCPv4_CLIENT link remote: [AF_INET]***.***.85.2:443
Sat Nov  1 01:15:22 2014 TLS: Initial packet from [AF_INET]***.***.85.2:443, sid=fd6756b9 823927f3
Sat Nov  1 01:15:22 2014 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Nov  1 01:15:22 2014 VERIFY OK: depth=1, /C=US/ST=FL/L=Winter_Park/O=vpnProvider/OU=vpnProvider_VPN/CN=vpnProvider_CA/emailAddress=support@vpnProvider.com
Sat Nov  1 01:15:22 2014 VERIFY X509NAME OK: /C=US/ST=FL/L=Winter_Park/O=vpnProvider/OU=vpnProvider_VPN/CN=vpn.vpnProvider.com/emailAddress=support@vpnProvider.com
Sat Nov  1 01:15:22 2014 VERIFY OK: depth=0, /C=US/ST=FL/L=Winter_Park/O=vpnProvider/OU=vpnProvider_VPN/CN=vpn.vpnProvider.com/emailAddress=support@vpnProvider.com
Sat Nov  1 01:15:23 2014 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sat Nov  1 01:15:23 2014 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Nov  1 01:15:23 2014 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sat Nov  1 01:15:23 2014 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Nov  1 01:15:23 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sat Nov  1 01:15:23 2014 [vpn.vpnProvider.com] Peer Connection Initiated with [AF_INET]***.***.85.2:443
Sat Nov  1 01:15:25 2014 SENT CONTROL [vpn.vpnProvider.com]: 'PUSH_REQUEST' (status=1)
Sat Nov  1 01:15:25 2014 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 198.18.0.1,dhcp-option DNS 198.18.0.2,rcvbuf 262144,explicit-exit-notify 5,route-gateway 172.20.24.1,topology subnet,ping 20,ping-restart 40,ifconfig 172.20.25.124 255.255.252.0'
Sat Nov  1 01:15:25 2014 OPTIONS IMPORT: timers and/or timeouts modified
Sat Nov  1 01:15:25 2014 OPTIONS IMPORT: --explicit-exit-notify can only be used with --proto udp
Sat Nov  1 01:15:25 2014 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sat Nov  1 01:15:25 2014 Socket Buffers: R=[131072->425984] S=[131072->131072]
Sat Nov  1 01:15:25 2014 OPTIONS IMPORT: --ifconfig/up options modified
Sat Nov  1 01:15:25 2014 OPTIONS IMPORT: route options modified
Sat Nov  1 01:15:25 2014 OPTIONS IMPORT: route-related options modified
Sat Nov  1 01:15:25 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Nov  1 01:15:25 2014 ROUTE_GATEWAY 10.194.0.1/255.255.248.0 IFACE=eth0 HWADDR=f0:de:f1:07:75:fd
Sat Nov  1 01:15:25 2014 TUN/TAP device tun0 opened
Sat Nov  1 01:15:25 2014 TUN/TAP TX queue length set to 100
Sat Nov  1 01:15:25 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Nov  1 01:15:25 2014 /sbin/ip link set dev tun0 up mtu 1500
Sat Nov  1 01:15:25 2014 /sbin/ip addr add dev tun0 172.20.25.124/22 broadcast 172.20.27.255
Sat Nov  1 01:15:25 2014 /sbin/ip route add ***.***.85.2/32 via 10.194.0.1
Sat Nov  1 01:15:25 2014 /sbin/ip route add 0.0.0.0/1 via 172.20.24.1
Sat Nov  1 01:15:25 2014 /sbin/ip route add 128.0.0.0/1 via 172.20.24.1
Sat Nov  1 01:15:25 2014 Initialization Sequence Completed


Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.20.24.1     128.0.0.0       UG    0      0        0 tun0
default         10.194.0.1      0.0.0.0         UG    1024   0        0 eth0
10.194.0.0      *               255.255.248.0   U     0      0        0 eth0
***.***.85.2     10.194.0.1      255.255.255.255 UGH   0      0        0 eth0
128.0.0.0       172.20.24.1     128.0.0.0       UG    0      0        0 tun0
172.20.24.0     *               255.255.252.0   U     0      0        0 tun0
--------------------------------------------------------------------------------

Non Working Syslog Log from NetworkManger + Route Table at end:

Nov  1 01:19:17 Laptop NetworkManager[783]: <info> Starting VPN service 'openvpn'...
Nov  1 01:19:17 Laptop NetworkManager[783]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 3119
Nov  1 01:19:17 Laptop NetworkManager[783]: <info> VPN service 'openvpn' appeared; activating connections
Nov  1 01:19:17 Laptop NetworkManager[783]: <info> VPN plugin state changed: starting (3)
Nov  1 01:19:17 Laptop NetworkManager[783]: nm-openvpn-Message: openvpn started with pid 3124
Nov  1 01:19:17 Laptop NetworkManager[783]: <info> VPN connection 'vpnProvider' (ConnectInteractive) reply received.
Nov  1 01:19:17 Laptop NetworkManager[783]: Sat Nov  1 01:19:17 2014 DEPRECATED OPTION: --tls-remote, please update your configuration
Nov  1 01:19:17 Laptop nm-openvpn[3124]: OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Mar 17 2014
Nov  1 01:19:17 Laptop nm-openvpn[3124]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov  1 01:19:17 Laptop nm-openvpn[3124]: Attempting to establish TCP connection with [AF_INET]***.***.85.3:443 [nonblock]
Nov  1 01:19:18 Laptop nm-openvpn[3124]: TCP connection established with [AF_INET]***.***.85.3:443
Nov  1 01:19:18 Laptop nm-openvpn[3124]: TCPv4_CLIENT link local: [undef]
Nov  1 01:19:18 Laptop nm-openvpn[3124]: TCPv4_CLIENT link remote: [AF_INET]***.***.85.3:443
Nov  1 01:19:19 Laptop nm-openvpn[3124]: [vpn.vpnProvider.com] Peer Connection Initiated with [AF_INET]***.***.85.3:443
Nov  1 01:19:22 Laptop nm-openvpn[3124]: TUN/TAP device tun0 opened
Nov  1 01:19:22 Laptop nm-openvpn[3124]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper --tun -- tun0 1500 1572 172.20.25.27 255.255.252.0 init
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> (tun0): carrier is OFF
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> (tun0): new Tun device (driver: 'unknown' ifindex: 6)
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/5
Nov  1 01:19:22 Laptop systemd-udevd[269]: Network interface NamePolicy= disabled on kernel commandline, ignoring.
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> VPN connection 'vpnProvider' (IP Config Get) reply received.
Nov  1 01:19:22 Laptop nm-openvpn[3124]: Initialization Sequence Completed
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> VPN connection 'vpnProvider' (IP4 Config Get) reply received.
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> VPN Gateway: ***.***.85.3
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Tunnel Device: tun0
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> IPv4 configuration:
Nov  1 01:19:22 Laptop NetworkManager[783]: <info>   Internal Gateway: 172.20.24.1
Nov  1 01:19:22 Laptop NetworkManager[783]: <info>   Internal Address: 172.20.25.27
Nov  1 01:19:22 Laptop NetworkManager[783]: <info>   Internal Prefix: 22
Nov  1 01:19:22 Laptop NetworkManager[783]: <info>   Internal Point-to-Point Address: 0.0.0.0
Nov  1 01:19:22 Laptop NetworkManager[783]: <info>   Maximum Segment Size (MSS): 0
Nov  1 01:19:22 Laptop NetworkManager[783]: <info>   Forbid Default Route: no
Nov  1 01:19:22 Laptop NetworkManager[783]: <info>   Internal DNS: 198.18.0.1
Nov  1 01:19:22 Laptop NetworkManager[783]: <info>   Internal DNS: 198.18.0.2
Nov  1 01:19:22 Laptop NetworkManager[783]: <info>   DNS Domain: '(none)'
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> No IPv6 configuration
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> (tun0): link connected
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> VPN connection 'vpnProvider' (IP Config Get) complete.
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> VPN plugin state changed: started (4)
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> NetworkManager state is now CONNECTED_LOCAL
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> NetworkManager state is now CONNECTED_GLOBAL
Nov  1 01:19:22 Laptop dbus[771]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> (tun0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> (tun0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) starting connection 'tun0'
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) scheduled...
Nov  1 01:19:22 Laptop dbus[771]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Nov  1 01:19:22 Laptop nm-dispatcher: Dispatching action 'vpn-up' for tun0
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) started...
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> (tun0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) scheduled...
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) complete.
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) starting...
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> (tun0): device state change: prepare -> config (reason 'none') [40 50 0]
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) successful.
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) scheduled.
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) complete.
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) started...
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> (tun0): device state change: config -> ip-config (reason 'none') [50 70 0]
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) complete.
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) started...
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) complete.
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Nov  1 01:19:22 Laptop NetworkManager[783]: <info> Activation (tun0) successful, device activated.
Nov  1 01:19:23 Laptop ntpd[859]: Listen normally on 10 tun0 172.20.25.27 UDP 123
Nov  1 01:19:23 Laptop ntpd[859]: ***.***.160.57 interface 10.194.4.254 -> 172.20.25.27
Nov  1 01:19:23 Laptop ntpd[859]: ***.***.246.10 interface 10.194.4.254 -> 172.20.25.27
Nov  1 01:19:23 Laptop ntpd[859]: ***.***.190.190 interface 10.194.4.254 -> 172.20.25.27
Nov  1 01:19:23 Laptop ntpd[859]: ***.***.164.1 interface 10.194.4.254 -> 172.20.25.27
Nov  1 01:19:23 Laptop ntpd[859]: peers refreshed
Nov  1 01:19:36 Laptop nm-dispatcher: Dispatching action 'up' for tun0

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.20.24.1     0.0.0.0         UG    1024   0        0 tun0
10.194.0.0      *               255.255.248.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     1000   0        0 tun0
172.20.24.0     *               255.255.252.0   U     0      0        0 tun0

--------------------------------------------------------------------------------
Comment 1 jljatone 2014-11-23 15:19:10 UTC 
Have you gone into the VPN settings IPv4 and IPv6 and checked the Use this connection only for resources on its network?

Personally I believe this should by default be set to true from a user standpoint.
Comment 2 mpz 2015-10-23 17:14:14 UTC 
I have exactly the same problem.

@jljatone Yes, it does not help.
Comment 3 François Kooman 2016-05-13 13:14:54 UTC 
The problem is the 'comp-lzo'. There are five possible scenarios in the client configuration:

1. comp-lzo yes
2. comp-lzo no
3. comp-lzo adaptive
4. comp-lzo
5. (nothing)

There are two subtle issue here (in NM 1.2):

*1*
3 and 4 are the same, but 3 is not accepted by NM.

*2* 
Scenario 2 and 5 are equal for NM while they are not equal for OpenVPN. OpenVPN allows the server to push comp-lzo (no matter whether it is enabled or disabled on the server!) in scenario 2, but not in scenario 5. A server that tries to push comp-lzo will break in scenario 2 with NM, but not with scenario 2 using OpenVPN cli.

The fix would be to have NM always specify comp-lzo when launching OpenVPN except in scenario 5 (when comp-lzo is completely missing from the client config) to match OpenVPN CLI behavior.

I used to have 2 in my VPN service's client config files, but now changed it to 4 which makes NM 1.2 work again, tested on Ubuntu 16.04 and Fedora 24 Beta.
Comment 4 Thomas Haller 2016-05-13 15:17:08 UTC 
(In reply to François Kooman from comment #3)
> The problem is the 'comp-lzo'. There are five possible scenarios in the
> client configuration:
> 

Hi,

how do you know that the reporter's issue is due to comp-lzo?
Comment 5 Thomas Haller 2016-05-13 15:17:19 UTC 
Created attachment 327796 [details] [review]
better support comp-lzo setting

Openvpn understands more options with --comp-lzo:

 1a) --comp-lzo
 1b) --comp-lzo adaptive
 2)  --comp-lzo yes
 3)  --comp-lzo no
 4)  (unspecified)

This already works for a long time, so it's safe to assume
that the openvpn version at hand understands these options
(https://github.com/OpenVPN/openvpn/commit/537073fd55b3e35720e759c5c13e9da128a2b0bb).

Add support for all combinations for import/export and running the
service.

But don't extend the GUI plugin. When configuring via gnome plugin,
it only understands 2) and 4).
Comment 6 Dan Williams 2016-05-13 15:27:51 UTC 
LGTM
Comment 7 Beniamino Galvani 2016-05-13 15:44:21 UTC 
Patch looks good.
Comment 8 Thomas Haller 2016-05-13 15:51:16 UTC 
patch merged

master: https://git.gnome.org/browse/network-manager-openvpn/commit/?id=2ecf18c25a7bee7f0122d9d666a7e11cd8b55ea3

nm-1-2: https://git.gnome.org/browse/network-manager-openvpn/commit/?id=b37fda4cc99470e7671a3da02f5d31d61f9ad243


I don't think the reporter had an issue with comp-lzo, thus the original bug is not fixed by this.
Comment 9 Thomas Haller 2016-05-13 15:54:35 UTC 
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> default         172.20.24.1     0.0.0.0         UG    1024   0        0 tun0
> 10.194.0.0      *               255.255.248.0   U     0      0        0 eth0
> link-local      *               255.255.0.0     U     1000   0        0 tun0
> 172.20.24.0     *               255.255.252.0   U     0      0        0 tun0


you see, that there is no direct route to the external VPN gateway. Thus, it tries to reach the VPN gateway via the VPN. That cannot work.


Compare:
> ***.***.85.2     10.194.0.1      255.255.255.255 UGH   0      0        0 eth0




Since 2014, the way how NetworkManager handles routes changed significantly, and this bug is very likely fixed.

Especially, NM adds a direct route along the underlay network.




Sorry for not coming back to this issue earlier.

If the issue still exists, please reopen with new logfiles.


Thank you.
Comment 10 François Kooman 2016-05-13 15:59:20 UTC 
(In reply to Thomas Haller from comment #4)
> how do you know that the reporter's issue is due to comp-lzo?

Actually I don't. It was a bit presumptuous of me... but this comp-lzo thing has the exact same symptoms. 

Looking further into it, it seems the message I'm getting in the NM log is not present in the log above:

May 13 17:57:42 localhost.localdomain nm-openvpn[2487]: WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'

Sorry for hijacking this report :(
Comment 11 Thomas Haller 2016-05-13 16:08:52 UTC 
(In reply to François Kooman from comment #10)
> (In reply to Thomas Haller from comment #4)
> > how do you know that the reporter's issue is due to comp-lzo?

> Sorry for hijacking this report :(

no problem :)
Comment 12 Federico Bruni 2016-05-13 16:24:35 UTC 
So the fix was pushed to version 1.2 branch also?
Should we expect to see (and test) it on Fedora24?

Thanks
Comment 13 Thomas Haller 2016-05-13 16:43:40 UTC 
Yes, it just missed 1.2.2 release, but will be in next minor release 1.2.4.

fc24 has has as of now 1.2.2-1. We either wait for 1.2.4-1, or possibly cherry-pick it earlier.
There is no plan to cherry-pick as the fix doesn't seem so urgent. We could do that, if strongly requested... (?).