Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1355688 - Openvpn wont connect nm-openvpn[1963]: Bad LZO decompression header byte: 42
Summary: Openvpn wont connect nm-openvpn[1963]: Bad LZO decompression header byte: 42
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager-openvpn
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1365663
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-12 09:09 UTC by Dr. David Alan Gilbert
Modified: 2016-08-27 10:39 UTC (History)
12 users (show)

Fixed In Version: NetworkManager-openvpn-1.2.4-2.fc24
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-13 20:21:24 UTC


Attachments (Terms of Use)

Description Dr. David Alan Gilbert 2016-07-12 09:09:01 UTC
Description of problem:
I can't connect this morning to our normal corporate OpenVPN (tried two different endpoints) and noticed that yesterday I'd had a NetworkManager-openvpn update.
I'm using the nm-applet (from an xfce desktop) to connect.

Version-Release number of selected component (if applicable):
NetworkManager-openvpn-1.2.4-1.fc24.x86_64
NetworkManager-1.2.2-2.fc24.x86_64


How reproducible:
Seems 100%

Steps to Reproduce:
1. Connect to preconfigured OpenVPN

Actual results:
Apparently connects; lock shown on the icon; but no traffic passes; noticed:
   nm-openvpn[1963]: Bad LZO decompression header byte: 42
  repeatedly in logs

Expected results:
A working connection.

Additional info:
I've not tried rolling back yet.

Comment 1 Dr. David Alan Gilbert 2016-07-12 18:54:13 UTC
OK, a bit more debugging.

1) My logs have the warning:
Jul 12 08:56:32 dgilbert-t530 nm-openvpn[1963]: WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'

that wasn't in yesterday's logs (journalctl -b-1 -u NetworkManager | grep -i lzo)
The nm-applet didn't show it as being on; so I tried turning it on and it didn't help - so I turned it back *off* and both that comp-lzo warning and the Bad LZO decompression warning have gone.

But I still don't get connectivity.

2) It looks like I'm not getting the route added that the server sent over;
I can see the IP Config Get reply, and see it has a Static Route entry (and that looks the same as yesterdays that worked), but 'ip route' doesn't show the route; if I add it manually it's working.

Comment 2 Dr. David Alan Gilbert 2016-07-13 10:50:37 UTC
The routing fixed itself after a reboot; so I think the only problem was that it was incorrectly turning lzo on even when I didn't originally have it enabled and which cleared when I turned it off on the gui and back on.

Comment 3 Nick Cross 2016-07-15 08:17:27 UTC
For reference, I am seeing this as well. I can confirm that I see 

Jul 11 10:53:41 atlantis nm-openvpn[3941]: WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'

followed by 

Jul 11 10:57:49 atlantis nm-openvpn[3941]: Bad LZO decompression header byte: 42

And although it states it has connected to the corporate vpn it has not. Downgrading to NetworkManager-openvpn-1:1.2.2-1.fc24.x86_64 from NetworkManager-openvpn-1:1.2.4-1.fc24.x86_64 fixed it.

I haven't (yet) tried the turning compression off/on again in the gui.

Comment 4 Nick Cross 2016-07-18 08:41:56 UTC
Tried compression on/off and a reboot and it still doesn't connect for me.

Comment 5 Dr. David Alan Gilbert 2016-07-18 08:51:34 UTC
(In reply to Nick Cross from comment #4)
> Tried compression on/off and a reboot and it still doesn't connect for me.

Has the 'comp-lzo' warning and 'Bad LZO decompression header' warning gone for you or is it still there?


Dave

Comment 6 Nick Cross 2016-07-18 08:56:24 UTC
Annoyingly its still there. I thought the recent Fed update might resolve it as well as there were bugs that might related to this? (bug 1327284)

Comment 7 Dr. David Alan Gilbert 2016-07-18 09:00:52 UTC
(In reply to Nick Cross from comment #6)
> Annoyingly its still there. I thought the recent Fed update might resolve it
> as well as there were bugs that might related to this? (bug 1327284)


Hmm if you've got those warnings then it sounds like it's not turned the compression off for you.  It's a bit difficult to know exactly which bit of fiddling did it for me; I think I tried turning it on and reconnecting, then when that failed turning it off and reconnecting.

Comment 8 Nick Cross 2016-07-18 09:40:37 UTC
I believe you're right. I think I'll have to have extended play with it at home when I have more time :-(

Comment 9 Nick Cross 2016-07-18 21:54:53 UTC
Are you using Gnome or KDE to connect?

I have

openvpn-2.3.11-1.fc24.x86_64
plasma-nm-openvpn-5.6.5-2.fc24.x86_64
NetworkManager-openvpn-1.2.2-1.fc24.x86_64

and that works fine. But with later NetworkManager-openvpn it fails (even after further attempts with different comp-lzo settings etc).

Comment 10 Dr. David Alan Gilbert 2016-07-19 08:19:51 UTC
(In reply to Nick Cross from comment #9)
> Are you using Gnome or KDE to connect?

xfce :-)

> I have
> 
> openvpn-2.3.11-1.fc24.x86_64
> plasma-nm-openvpn-5.6.5-2.fc24.x86_64
> NetworkManager-openvpn-1.2.2-1.fc24.x86_64
> 
> and that works fine. But with later NetworkManager-openvpn it fails (even
> after further attempts with different comp-lzo settings etc).


NetworkManager-openvpn-gnome-1.2.4-1.fc24.x86_64
NetworkManager-openvpn-1.2.4-1.fc24.x86_64
openvpn-2.3.11-1.fc24.x86_64
network-manager-applet-1.2.0-1.fc24.x86_64
nm-connection-editor-1.2.0-1.fc24.x86_64

I start the VPN using the nm-applet widget, which seems to come from network-manager-applet.
Editing seems to be done by nm-connection-editor.

Dave

Comment 11 Nick Cross 2016-07-19 09:24:05 UTC
Thanks for that! 

I installed NetworkManager-openvpn-gnome network-manager-applet and configured using them my VPN targets as per your instructions. Interestingly "comp-lzo=no" then disappeared from  /etc/NetworkManager/system-connections/ovpn-*

And now I have a successful connection. 

My guess is while the network-manager-applet correctly edited the connection to remove the option the kde version didn't?

Comment 12 Dr. David Alan Gilbert 2016-07-19 09:52:51 UTC
(In reply to Nick Cross from comment #11)
> Thanks for that! 
> 
> I installed NetworkManager-openvpn-gnome network-manager-applet and
> configured using them my VPN targets as per your instructions. Interestingly
> "comp-lzo=no" then disappeared from 
> /etc/NetworkManager/system-connections/ovpn-*
> 
> And now I have a successful connection. 
> 
> My guess is while the network-manager-applet correctly edited the connection
> to remove the option the kde version didn't?

Possibly; now I used to use KDE as well (back in f22 days) which makes me wonder if I used to have the 'comp-lzo=no' and that's the problem, perhaps this new nm-openvpn doesn't understand that?

There's this comment in the source (properties/auth-helpers.c) but I don't know the details;

        if (NM_IN_STRSET (value, "yes", "adaptive")) {
                /* the UI currently only supports "--comp-lzo yes" or omitting the "--comp-lzo"
                 * flag.
                 *
                 * Internally, we also support "--comp-lzo [adaptive]" and "--comp-lzo no"
                 * which have different meaning for openvpn. */
                widget = GTK_WIDGET (gtk_builder_get_object (builder, "lzo_checkbutton"));
                gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (widget), TRUE);
        }

Comment 13 Dr. David Alan Gilbert 2016-07-19 10:00:39 UTC
That comment comes from Thomas's b37fda commit;  Thomas what do you reckon? Is this a behaviour with a comp-lzo=no - perhaps the KDE setup was setting that and then breaks on this upgrade?

Dave

Comment 14 Nick Cross 2016-07-19 10:08:38 UTC
Is this related? : https://bugs.kde.org/show_bug.cgi?id=365816

Comment 15 Randy Barlow 2016-07-19 22:31:08 UTC
I am also experiencing this issue on KDE (using the KDE applet). I tried to manually remove comp-lzo=no in my /etc/NetworkManager/system-connections/ file, but when I used the KDE applet to connect I guess it changed it back to the way it used to be. I then tried to edit it by hand and use the nmcli tool to bring the VPN up, and it came back again. Any ideas for alternative workarounds to using the Gnome applet?

Comment 16 Randy Barlow 2016-07-20 00:49:21 UTC
I downgraded to NetworkManager-openvpn-1.2.2-1.fc24 and that resolved the issue for me.

https://bodhi.fedoraproject.org/updates/FEDORA-2016-73f517cf1a

Comment 17 Nick Cross 2016-07-20 06:56:44 UTC
@Randy : as per comment 11 I reconfigured my connections using the gnome applet. I then removed NetworkManager-openvpn-gnome network-manager-applet and have since been able to connect successfully using KDE. Although I daren't touch the KDE configuration as I suspect its not handling the options correctly. Possibly this commit http://commits.kde.org/plasma-nm/31bcd5f2cffd1c19fbd10ab0f4172f2d82eff194 from the bug referenced on comment 14 might help

Comment 18 Thom Carlin 2016-07-28 12:19:17 UTC
Comment 11 also worked for me.

Some diagnostic tips if it connects but doesn't route:
1) ip address show dev tun0
   Get the IP address
2) ping <<tun_ip_address>>
   The pings worked for me
3) ip route | grep tun0
   Get the gateway (the "via " argument)
4) ping <<tun_gateway_ip_address>>
   The pings failed for me
5) Try: openvpn --config <<openvpn_config_file>>
   If it works, the interaction is with NetworkManager and OpenVPN

Comment 19 Hynek Mlnarik 2016-08-02 18:10:34 UTC
I have same experience, workaround from comment 11 solved the issue for me.

Comment 20 Thom Carlin 2016-08-05 11:48:03 UTC
I also removed plasma-nm

Comment 21 Blueowl 2016-08-09 16:33:11 UTC
plasma-nm used to put comp-lzo=no if the checkbox was not checked (opposed to nm-connection-editor that sets nothing). But networkmanager-openvpn worked with that because it was only interested in comp-lzo=yes.
However, with https://git.gnome.org/browse/network-manager-openvpn/commit/?id=2ecf18c25a7bee7f0122d9d666a7e11cd8b55ea3 commit, networkmanager-openvpn pays attention to all comp-lzo values and thus comp-lzo=no setting added with plasma-nm really became "--comp-lzo no" passed to openvpn.

Nevertheless, the mentioned plasma-nm commit https://quickgit.kde.org/?p=plasma-nm.git&a=commit&h=31bcd5f2cffd1c19fbd10ab0f4172f2d82eff194 should fix the issue, because it adds a combobox to the checkbox, and puts comp-lzo=something to the configuration only if the checkbox is checked.

Comment 22 Randy Barlow 2016-08-09 19:20:25 UTC
I filed an issue against plasma-nm (for KDE) to ask for that patch to be backported. Perhaps we each need to report this problem against the specific NM widgets we use and mark them each as blocking this issue?

Comment 23 Randy Barlow 2016-08-10 20:18:32 UTC
plasma-nm users: please test the plasma-nm updates in Bodhi from https://bugzilla.redhat.com/show_bug.cgi?id=1365663 and report on Bodhi if they work for you. Jan Grulich was kind enough to backport the patch that Blueowl mentioned for us to try out!

Comment 24 Thomas Haller 2016-08-11 09:26:17 UTC
I agree with the analysis of comment 21. Together with a new nm-openvpn, an explicit comp-lzo=no setting is now interpreted differently from an absent comp-lzo setting.

plasma-nm UI should be updated [1], to either support all 4 options that openvpn support [2].
Alternativly, it should behave like nm-connection-editor which only supports 2 options a boolean checkbox, but where an unchecked comp-lzo option means not "comp-lzo=no" but ~no comp-lzo~.


[1] https://quickgit.kde.org/?p=plasma-nm.git&a=commit&h=31bcd5f2cffd1c19fbd10ab0f4172f2d82eff194
[2] https://git.gnome.org/browse/network-manager-openvpn/commit/?id=2ecf18c25a7bee7f0122d9d666a7e11cd8b55ea3
[3] https://git.gnome.org/browse/network-manager-openvpn/diff/properties/auth-helpers.c?id=2ecf18c25a7bee7f0122d9d666a7e11cd8b55ea3



This only affects users who used plasma-nm to create a connection and now have in their connection wrongly "comp-lzo=no". See the output of `nmcli connection show $OVPN_CONNECTION`.
I think the fix here is to edit the connection and remove the comp-lzo setting -- for example by editing the connection in nm-connection-editor.

It's bad to break existing connections, but IMO it is really caused by a subtle bug in plasma-nm. So I think the acceptable fix is to require the user to fix the wrongly created connection.

Comment 25 Thomas Haller 2016-08-11 14:23:20 UTC
this is now fixed in upstream nm-openvpn: https://bugzilla.gnome.org/show_bug.cgi?id=769177#c7

Comment 26 Fedora Update System 2016-08-11 15:13:39 UTC
NetworkManager-openvpn-1.2.4-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9565d84a71

Comment 27 Fedora Update System 2016-08-11 15:16:21 UTC
NetworkManager-openvpn-1.2.4-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-645466c626

Comment 28 Fedora Update System 2016-08-12 03:02:15 UTC
NetworkManager-openvpn-1.2.4-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9565d84a71

Comment 29 Fedora Update System 2016-08-12 14:28:45 UTC
NetworkManager-openvpn-1.2.4-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-645466c626

Comment 30 Fedora Update System 2016-08-13 20:21:17 UTC
NetworkManager-openvpn-1.2.4-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 31 Fedora Update System 2016-08-27 10:39:23 UTC
NetworkManager-openvpn-1.2.4-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.