Bug 1030068 - NetworkManager expects tun0 device from libreswan
NetworkManager expects tun0 device from libreswan
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Dan Williams
Desktop QE
: Regression
Depends On:
Blocks: 921061 999353
  Show dependency treegraph
 
Reported: 2013-11-13 16:00 EST by Avesh Agarwal
Modified: 2014-06-17 22:50 EDT (History)
11 users (show)

See Also:
Fixed In Version: NetworkManager-0.9.9.0-36.git20140127
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 08:41:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 721724 None None None Never

  None (edit)
Description Avesh Agarwal 2013-11-13 16:00:15 EST
Description of problem:
Networkmanager expects tun0 device from libreswan when libreswan (fork of openswan) does not provide any such device. This works fine on rhel6 with openswan, so this issue is regression. 

Version-Release number of selected component (if applicable):

NetworkManager-0.9.9.0-20.git20131108.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. configure a vpn with libreswan
2. connect the vpn.
3.

Actual results:
The logs shows following errors:

Nov 13 15:10:59 dhcp129-63 NetworkManager[704]: <info> VPN connection 'jsgnjsmtest' (Connect) reply received.
Nov 13 15:11:00 dhcp129-63 NetworkManager[704]: <info> VPN connection 'jsgnjsmtest' (IP4 Config Get) reply received from old-style plugin.
Nov 13 15:11:00 dhcp129-63 NetworkManager[704]: <error> [1384373460.3025] [vpn-manager/nm-vpn-connection.c:746] process_generic_config(): (tun0): failed to look up VPN interface index
Nov 13 15:11:00 dhcp129-63 NetworkManager[704]: <warn> VPN connection 'jsgnjsmtest' did not receive valid IP config information.


Nov 13 15:42:31 dhcp129-63 NetworkManager[704]: <info> VPN connection 'jsgnjsmtest' (Connect) reply received.
Nov 13 15:42:32 dhcp129-63 NetworkManager[704]: <info> VPN connection 'jsgnjsmtest' (IP4 Config Get) reply received from old-style plugin.
Nov 13 15:42:32 dhcp129-63 NetworkManager[704]: <error> [1384375352.232103] [vpn-manager/nm-vpn-connection.c:738] process_generic_config(): invalid or missing tunnel device received!
Nov 13 15:42:32 dhcp129-63 NetworkManager[704]: <warn> VPN connection 'jsgnjsmtest' did not receive valid IP config information.


Expected results:
NetworkManager should not expect tun0 interface from libreswan.


Additional info:
Comment 3 Dan Williams 2013-11-13 21:32:59 EST
Is this a regression from previous versions of NetworkManager in RHEL7?  Is the behavior of upstream Fedora 20 NetworkManager different here than what's in RHEL7?
Comment 4 Avesh Agarwal 2013-11-14 09:37:14 EST
(In reply to Dan Williams from comment #3)
> Is this a regression from previous versions of NetworkManager in RHEL7?  Is
> the behavior of upstream Fedora 20 NetworkManager different here than what's
> in RHEL7?

This is a regression from RHEL6. openswan/libreswan do not provide tun0 interface.
Comment 5 Avesh Agarwal 2013-11-14 09:44:33 EST
There is related issue which has been since f18:

https://bugzilla.redhat.com/show_bug.cgi?id=865883
Comment 6 Dan Williams 2013-12-23 13:26:17 EST
Fixes pushed upstream to dcbw/vpn-no-iface for review.

There are one or two other fixes, but this branch enables NetworkManager-openswan with libreswan 3.7 to work with the Red Hat VPN, after disabling the NM-openswan tunnel interface hack.
Comment 7 Dan Williams 2013-12-23 13:41:58 EST
Avesh; eventually NetworkManager-openswan should simply not pass any tunnel interface at all, instead of the current workarounds.  Obviously that's not backwards compatible right now, so in the dcbw/vpn-no-iface branch NetworkManager also recognizes "_none_" as a NULL tunnel interface name.  We should continue to use "_none_" until we can switch NM-openswan over to passing no tunnel interface name at all.
Comment 8 Avesh Agarwal 2013-12-23 14:31:02 EST
(In reply to Dan Williams from comment #7)
> Avesh; eventually NetworkManager-openswan should simply not pass any tunnel
> interface at all, instead of the current workarounds.  Obviously that's not
> backwards compatible right now, so in the dcbw/vpn-no-iface branch
> NetworkManager also recognizes "_none_" as a NULL tunnel interface name.  We
> should continue to use "_none_" until we can switch NM-openswan over to
> passing no tunnel interface name at all.

The latest changes in rhel and fedora pass "none" as tunnel interface. The patch 0007-openswan-libreswan-does-not-provide-tun0-interface-s.patch does this. So NM-openswan seems good w.r.t. this.
Comment 9 Thomas Haller 2014-01-03 17:07:50 EST
(In reply to Dan Williams from comment #6)
> Fixes pushed upstream to dcbw/vpn-no-iface for review.


>> dns-manager: allow NULL interface name for IP configs

We set also the tag IP_CONFIG_IFACE_TAG for NMIP4Config, but it is never used there.

also, I would:
  +   g_assert (!g_object_get_data (G_OBJECT (config, IP_CONFIG_IFACE_TAG)); 
      if (iface)
          g_object_set_data_full (G_OBJECT (config), IP_CONFIG_IFACE_TAG...



Appart from that, it looks good to me (I did not test it).
Comment 10 Dan Williams 2014-01-06 16:39:56 EST
(In reply to Avesh Agarwal from comment #8)
> (In reply to Dan Williams from comment #7)
> > Avesh; eventually NetworkManager-openswan should simply not pass any tunnel
> > interface at all, instead of the current workarounds.  Obviously that's not
> > backwards compatible right now, so in the dcbw/vpn-no-iface branch
> > NetworkManager also recognizes "_none_" as a NULL tunnel interface name.  We
> > should continue to use "_none_" until we can switch NM-openswan over to
> > passing no tunnel interface name at all.
> 
> The latest changes in rhel and fedora pass "none" as tunnel interface. The
> patch 0007-openswan-libreswan-does-not-provide-tun0-interface-s.patch does
> this. So NM-openswan seems good w.r.t. this.

Do the pass "none" or "_none_"?  I picked "_none_" because that seems much less likely to ever be an interface name, while "none" technically is valid.
Comment 11 Avesh Agarwal 2014-01-06 16:43:34 EST
(In reply to Dan Williams from comment #10)
> (In reply to Avesh Agarwal from comment #8)
> > (In reply to Dan Williams from comment #7)
> > > Avesh; eventually NetworkManager-openswan should simply not pass any tunnel
> > > interface at all, instead of the current workarounds.  Obviously that's not
> > > backwards compatible right now, so in the dcbw/vpn-no-iface branch
> > > NetworkManager also recognizes "_none_" as a NULL tunnel interface name.  We
> > > should continue to use "_none_" until we can switch NM-openswan over to
> > > passing no tunnel interface name at all.
> > 
> > The latest changes in rhel and fedora pass "none" as tunnel interface. The
> > patch 0007-openswan-libreswan-does-not-provide-tun0-interface-s.patch does
> > this. So NM-openswan seems good w.r.t. this.
> 
> Do the pass "none" or "_none_"?  I picked "_none_" because that seems much
> less likely to ever be an interface name, while "none" technically is valid.

See below:

#define NM_VPN_PLUGIN_IP4_CONFIG_TUNDEV_NONE "_none_"

So seems fine as you explained.
Comment 12 Dan Williams 2014-01-06 16:56:16 EST
(In reply to Thomas Haller from comment #9)
> (In reply to Dan Williams from comment #6)
> > Fixes pushed upstream to dcbw/vpn-no-iface for review.
> 
> 
> >> dns-manager: allow NULL interface name for IP configs
> 
> We set also the tag IP_CONFIG_IFACE_TAG for NMIP4Config, but it is never
> used there.
> 
> also, I would:
>   +   g_assert (!g_object_get_data (G_OBJECT (config, IP_CONFIG_IFACE_TAG)); 
>       if (iface)
>           g_object_set_data_full (G_OBJECT (config), IP_CONFIG_IFACE_TAG...
> 
> 
> 
> Appart from that, it looks good to me (I did not test it).

actually, I think just removing the "if (iface)" should be sufficient, since IP_CONFIG_IFACE_TAG should always follow the 'iface' here.  g_strdup(NULL) returns NULL, so that would correctly clear the tag if it was previously set.
Comment 14 Dan Williams 2014-01-24 13:00:52 EST
upstream dcbw/vpn-no-iface branch merged to git master.
Comment 15 Dan Williams 2014-02-19 22:38:55 EST
Actually been in RHEL7 builds since 2014-01-27...
Comment 17 Vladimir Benes 2014-03-12 10:07:49 EDT
connecting via libreswan to vpn works as expected
Comment 18 Ludek Smid 2014-06-13 08:41:48 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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