Bug 1139536 - [RFE] Improve handling of DEVICE and HWADDR in nm-connection-editor
Summary: [RFE] Improve handling of DEVICE and HWADDR in nm-connection-editor
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: network-manager-applet
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: 7.2
Assignee: Jirka Klimes
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-09 07:23 UTC by Marko Myllynen
Modified: 2015-11-19 10:57 UTC (History)
13 users (show)

Fixed In Version: network-manager-applet-1.0.3-2.git20150617.a0b0166.el7
Doc Type: Enhancement
Doc Text:
It is now possible to specify an interface name instead of a MAC address when editing a connection using nm-connection-editor.
Clone Of:
Environment:
Last Closed: 2015-11-19 10:57:19 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:2315 normal SHIPPED_LIVE Moderate: NetworkManager security, bug fix, and enhancement update 2015-11-19 10:06:58 UTC

Description Marko Myllynen 2014-09-09 07:23:24 UTC
Description of problem:
When installing RHEL 7 guest from RHEL 7.0 DVD using all defaults on a RHEL 6 host, after booting up the system eth0 comes up with "ifup eth0" as expected. After applying updates, disabling NM and enabling network, and changing ONBOOT=yes, everything still works ok after reboot. However, if I remove HWADDR line from ifcfg-eth0 (as part of preparation to clone the guest), the device is not activated after next the reboot.

It turns out that initscripts expect either HWADDR and/or DEVICE to be present but on RHEL 7.0 in this case after installation we have only HWADDR and NAME=eth0, not DEVICE. On RHEL 5 / RHEL 6 in similar case we had DEVICE=eth0 present but not NAME=eth0.

Filing initially againt initscripts to allow Lukáš to provide more insights.

Comment 2 Lukáš Nykrýn 2014-09-09 09:38:28 UTC
By the way this is a little bit related to this issue. https://bugzilla.redhat.com/show_bug.cgi?id=1087945

Comment 3 Lukáš Nykrýn 2014-09-09 10:06:36 UTC
There is nothing what we can do in initscripts. Simply we need either DEVICE or HWADDR in configuration file.

I think that there are two issues which should be fixed.

1) connection manager should use matching by device by default-

2) sys-virtprep should no create invalid configuration from valid ifcfg file.

Comment 4 Marko Myllynen 2014-09-09 10:12:02 UTC
(In reply to Lukáš Nykrýn from comment #3)
> There is nothing what we can do in initscripts. Simply we need either DEVICE
> or HWADDR in configuration file.

Yup, could you please re-assign this to the most likely party then, perhaps anaconda or dracut?

> 2) sys-virtprep should no create invalid configuration from valid ifcfg file.

This happens also without virt-sysprep although most often this is noticed with it. Just use the steps outlined in comment 0 and you can reproduce this without virt-sysprep.

Thanks.

Comment 6 Lukáš Nykrýn 2014-09-09 10:36:56 UTC
> > 2) sys-virtprep should no create invalid configuration from valid ifcfg file.
> 
> This happens also without virt-sysprep although most often this is noticed
> with it. Just use the steps outlined in comment 0 and you can reproduce this
> without virt-sysprep.
If you don't have HWADDR or DEVICE in your ifcfg file, then it is simply invalid configuration.
We can't use the NAME variable. That is variable of NetworkManager and it is not specified that it will match the name of the device.

Comment 7 Marko Myllynen 2014-09-18 09:37:52 UTC
Note that although virt-sysprep is not involved reproducing this, the issue prevent creating clones with working network using virt-sysprep/virt-clone.

Comment 9 Jirka Klimes 2014-10-02 09:01:00 UTC
The base of the issues is that ifcfg files are used by two systems, legacy initscripts and NetworkManager. And also that there are number of components that creates and modifies ifcfg files. It is not a problem per se. However, they should play in concert.

As said initscrips needs one of HWADDR or DEVICE to match the device. But it seems that dracut/anaconda puts one of them in the file.
https://bugzilla.redhat.com/show_bug.cgi?id=1040461#c15
And it seems that they will switch (switched) from HWADDR to DEVICE (interface names should be stable now).

So if some script edits an ifcfg file and wants it to be usable by initscripts it has to retain the HWADDR, or DEVICE. Because traditionally there's one ifcfg file per device and the matching is done by the variables.

NetworkManager extends this a bit (because it handles ifcfg as connection profiles) and allows missing HWADDR and DEVICE. In that case the file is applicable to any matching device (e.g. Ethernet).

What could be done on NM side to improve the situation is:
* consider whether the generic NM profiles (without specific MAC and device name) shouldn't be written rather to /etc/NetworkManager/system-connections instead of ifcfg
* enhance nm-connection-editor to be able to create files only with DEVICE. Now, if it "bind" the file, it uses HWADDR.

However, the root cause here is that a script removes a piece of information from ifcfg file and makes it invalid.

Comment 10 Jirka Klimes 2015-02-19 09:50:17 UTC
The original issue was caused by incorrect modification of ifcfg files, so not a bug.
However, I change the bugzilla to a RFE for potential improvements mentioned in comment #9.

Comment 12 Jirka Klimes 2015-03-16 16:27:14 UTC
(In reply to Jirka Klimes from comment #9)
> What could be done on NM side to improve the situation is:
> * enhance nm-connection-editor to be able to create files only with DEVICE.
> 

Added the UI to nm-connection-editor to be able to set interface name. See upstream branch jk/editor-interface-name-rh1139536.

Comment 13 Dan Winship 2015-03-18 18:47:35 UTC
In nmtui, I made interface name and hwaddr be a single widget. I never implemented the pop-up part of it, so for now it's just an entry that accepts either an ifname or a MAC address. When displaying an existing connection, if it has an interface-name or mac-address that refers to a known device, then it will show the other datum in parentheses (ie, something like "enp0s25 (f0:de:f1:9b:15:37)" if interface-name is set, or "f0:de:f1:9b:15:37 (enp0s25)" if mac-address is set, just like the nm-c-e combo boxes).

I don't remember if it tries to deal with connections that have both interface-name and mac-address set... that didn't seem like a very useful use case anyway.

Anyway, I'm biased, but I think this makes more sense than having them be separate (especially since the MAC combo shows interface names as well).

>+static GType
>+get_device_type (CEPageGeneral *self)

libnm has nm_device_get_setting_type(), which is basically the opposite of this. I wonder if we could add nm_setting_get_device_type()? That wouldn't have been possible in libnm-util/libnm-glib, but maybe we can make it work in libnm? (The biggest problem is that nm_device_wifi_get_type() wouldn't be resolvable at link time in the daemon, since that would be from a plugin...)

Comment 14 Jirka Klimes 2015-05-14 10:05:20 UTC
(In reply to Dan Winship from comment #13)
> In nmtui, I made interface name and hwaddr be a single widget. I never
> implemented the pop-up part of it, so for now it's just an entry that
> accepts either an ifname or a MAC address. When displaying an existing
> connection, if it has an interface-name or mac-address that refers to a
> known device, then it will show the other datum in parentheses (ie,
> something like "enp0s25 (f0:de:f1:9b:15:37)" if interface-name is set, or
> "f0:de:f1:9b:15:37 (enp0s25)" if mac-address is set, just like the nm-c-e
> combo boxes).
> 
> I don't remember if it tries to deal with connections that have both
> interface-name and mac-address set... that didn't seem like a very useful
> use case anyway.
> 
> Anyway, I'm biased, but I think this makes more sense than having them be
> separate (especially since the MAC combo shows interface names as well).
> 

I renamed "Device MAC Address:" combo boxes to "Device:" and it now allows:

enps025
f0:de:f1:9b:15:37
enp0s25 (f0:de:f1:9b:15:37)
f0:de:f1:9b:15:37 (enp0s25)

So, either both interface name and MAC address can be set, or just one of them, or none.

> >+static GType
> >+get_device_type (CEPageGeneral *self)
> 
> libnm has nm_device_get_setting_type(), which is basically the opposite of
> this. I wonder if we could add nm_setting_get_device_type()? That wouldn't
> have been possible in libnm-util/libnm-glib, but maybe we can make it work
> in libnm? (The biggest problem is that nm_device_wifi_get_type() wouldn't be
> resolvable at link time in the daemon, since that would be from a plugin...)

The function is not needed any more after the rework, because the code is now in particular pages, not the general one.

The upstream branch jk/editor-interface-name-rh1139536 has been re-pushed.

Comment 15 Dan Williams 2015-05-15 22:05:56 UTC
page-wifi.c: In function ‘validate’:
page-wifi.c:540:49: error: ‘bssid’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
                NM_SETTING_WIRELESS_BSSID, bssid && *bssid ? bssid : NULL,
                                                 ^
page-wifi.c:495:14: note: ‘bssid’ was declared here
  const char *bssid;
              ^

Rest looks OK to me.

Comment 16 Jirka Klimes 2015-05-18 10:58:07 UTC
(In reply to Dan Williams from comment #15)
> page-wifi.c: In function ‘validate’:
> page-wifi.c:540:49: error: ‘bssid’ may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
>                 NM_SETTING_WIRELESS_BSSID, bssid && *bssid ? bssid : NULL,
>                                                  ^
> page-wifi.c:495:14: note: ‘bssid’ was declared here
>   const char *bssid;
>               ^
Fixed.

> 
> Rest looks OK to me.

Committed to upstream master as
2861681 editor: let users edit connection.interface-name property (rh #1139536)

Comment 19 Jirka Klimes 2015-06-17 10:41:39 UTC
(In reply to Jirka Klimes from comment #16)
> 
> Committed to upstream master as
> 2861681 editor: let users edit connection.interface-name property (rh
> #1139536)

Backported to nma-1-0:
a0b0166 editor: let users edit connection.interface-name property (rh #1139536)

Comment 24 Matěj Cepl 2015-10-01 17:48:41 UTC
> * enhance nm-connection-editor to be able to create files only with DEVICE.
> Now, if it "bind" the file, it uses HWADDR.

Using nm-connection-editor from nm-connection-editor-1.0.6-1.el7.x86_64 I can create configuration just with DEVICE:

TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
IPV6_PRIVACY=no
NAME="Ethernet connection 1"
UUID=8556c4fc-a9d2-460d-bbe1-aeacb173164b
DEVICE=eth0
ONBOOT=yes

Comment 25 errata-xmlrpc 2015-11-19 10:57:19 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-2315.html


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