This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1309661 - For static iBFT configuration editable ibft0 connection is exposed in Anaconda UI [NEEDINFO]
For static iBFT configuration editable ibft0 connection is exposed in Anacond...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Radek Vykydal
Release Test Team
:
Depends On: 1352005
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-18 06:44 EST by Radek Vykydal
Modified: 2017-10-06 14:05 EDT (History)
7 users (show)

See Also:
Fixed In Version: anaconda-21.48.22.87-1
Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 19:22:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rvykydal: needinfo? (harald)


Attachments (Terms of Use)
NetworkManager debug log (201.33 KB, text/plain)
2016-02-18 06:44 EST, Radek Vykydal
no flags Details

  None (edit)
Description Radek Vykydal 2016-02-18 06:44:30 EST
Created attachment 1128189 [details]
NetworkManager debug log

Description of problem:

If static network configuration is defined in iBFT and ip=ibft boot option is used, the configuration activated in initramfs (based on the boot option) is exposed as ibft0 connection editable in GUI after switchroot. iBFT connections are read-only and should not be exposed by the GUI.

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

RHEL 7.2

How reproducible:

Always

Steps to Reproduce:
1. set up static ipv4 configuration in iBFT
2. start installation with ip=ibft option
3. in GUI see ibft0 device in network spoke

Actual results:

3. above

Expected results:

ibft0 device should not be exposed in network configuration GUI as its configuration is set up in iBFT firmware.

Additional info:

After switchroot, NetworkManager reads iBFT configuration, creates corresponding read-only connection "iBFT ibft0". It should match the connection created in the initramfs but it does not. As a consequence NM creates another connection "ibft0" for the one created in initramfs. This connection is editable in Anaconda GUI.

For dhcp iBFT configuration matching works and no additional connection is created by NM.

ifcfg.log:

15:01:32,111 DEBUG ifcfg: content of files (network initialization):
15:01:32,111 DEBUG ifcfg: /etc/sysconfig/network-scripts/ifcfg-ibft0:
15:01:32,111 DEBUG ifcfg:   # Generated by dracut initrd
15:01:32,112 DEBUG ifcfg:   NAME="ibft0"
15:01:32,112 DEBUG ifcfg:   HWADDR="00:15:17:96:75:0a"
15:01:32,112 DEBUG ifcfg:   DEVICE="ibft0"
15:01:32,112 DEBUG ifcfg:   ONBOOT=yes
15:01:32,112 DEBUG ifcfg:   NETBOOT=yes
15:01:32,112 DEBUG ifcfg:   UUID="e4bc2ec9-bbf7-427f-acd1-7ca1e94339eb"
15:01:32,112 DEBUG ifcfg:   BOOTPROTO=ibft
15:01:32,112 DEBUG ifcfg:   GATEWAY="10.34.102.254"
15:01:32,113 DEBUG ifcfg:   TYPE=Ethernet

The ifcfg file should not contain GATEWAY but this is irrelevant for this bug because ifcfg files with BOOTPROTO=ibft are intentionally ignored by NM (ibft configuration is handled by NM ibft plugin since 7.2).


15:01:32,126 DEBUG ifcfg: all settings: [

The "iBFT ibft0" connection created by NM ibft plugin based on iBFT config ...

{'802-3-ethernet': {'mac-address-blacklist': [], 's390-options': {}, 'mac-address': [0, 21, 23, 150, 117, 10]}, 'connection': {'uuid': 'cc74a62a-adbd-37e0-a26e-c62260adeae7', 'id': 'iBFT ibft0', 'type': '802-3-ethernet', 'secondaries': [], 'read-only': True, 'permissions': []}, 'ipv4': {'addresses': [[1399202314L, 24L, 4268106250L]], 'dns-search': [], 'gateway': '10.34.102.254', 'route-data': [], 'dns': [], 'routes': [], 'address-data': [{'prefix': 24L, 'address': '10.34.102.83'}], 'method': 'manual'}, 'ipv6': {'addresses': [], 'dns-search': [], 'route-data': [], 'dns': [], 'routes': [], 'address-data': [], 'method': 'auto'}},

... has ipv6 method "auto"

The connection created for initramfs connection:

{'802-3-ethernet': {'mac-address-blacklist': [], 's390-options': {}, 'mac-address': [0, 21, 23, 150, 117, 10]}, 'connection': {'autoconnect': False, 'uuid': 'd83e26fb-948d-4338-9680-de708367f787', 'timestamp': 1455721285L, 'secondaries': [], 'interface-name': 'ibft0', 'type': '802-3-ethernet', 'id': 'ibft0', 'permissions': []}, 'ipv4': {'route-metric': 0L, 'addresses': [[1399202314L, 24L, 4268106250L]], 'dns-search': [], 'gateway': '10.34.102.254', 'route-data': [], 'dns': [], 'routes': [], 'address-data': [{'prefix': 24L, 'address': '10.34.102.83'}], 'method': 'manual'}, 'ipv6': {'addresses': [], 'dns-search': [], 'route-data': [], 'dns': [], 'routes': [], 'address-data': [], 'method': 'ignore'}}]

... has ipv6 method "ignore'.

from attached syslog:
11:37:35,026 INFO NetworkManager: <debug> [1455795455.026696] [NetworkManagerUtils.c:2164] nm_utils_match_connection(): Connection 'ibft0' differs from candidate 'iBFT ibft0' in connection.interface-name, ipv6.method


Dracut does not autoconfigure ipv6 for static (ipv4) configuration in iBFT while it does for dhcp configuration set in iBFT (it applies to ipv4 configuration via ip= options as well).
Comment 2 Radek Vykydal 2016-02-18 06:47:10 EST
(In reply to Radek Vykydal from comment #0)
 
> Dracut does not autoconfigure ipv6 for static (ipv4) configuration in iBFT
> while it does for dhcp configuration set in iBFT (it applies to ipv4
> configuration via ip= options as well).

Harald, is it expected behavior?
Comment 3 Harald Hoyer 2016-03-10 07:41:18 EST
(In reply to Radek Vykydal from comment #2)
> (In reply to Radek Vykydal from comment #0)
>  
> > Dracut does not autoconfigure ipv6 for static (ipv4) configuration in iBFT
> > while it does for dhcp configuration set in iBFT (it applies to ipv4
> > configuration via ip= options as well).
> 
> Harald, is it expected behavior?

The dhclient-script handles BOUND6.

In case of iBFT dhcp, "ip=ibft0:dhcp" is injected in the cmdline handling.
In this case "dhclient -4" is called. From the man page:
       -4     Use the DHCPv4 protocol to obtain an IPv4 address and configuration parameters.  This is the default and cannot be combined with -6.

I am not sure, what dhclient does, but I was not assuming any IPv6 config was done by it. dracut itsself does no IPv6 for dhcp only for ip=dhcp6
Comment 4 Radek Vykydal 2016-03-29 09:41:37 EDT
(In reply to Harald Hoyer from comment #3)
> (In reply to Radek Vykydal from comment #2)
> > (In reply to Radek Vykydal from comment #0)
> >  
> > > Dracut does not autoconfigure ipv6 for static (ipv4) configuration in iBFT
> > > while it does for dhcp configuration set in iBFT (it applies to ipv4
> > > configuration via ip= options as well).
> > 
> > Harald, is it expected behavior?
> 
> The dhclient-script handles BOUND6.
> 
> In case of iBFT dhcp, "ip=ibft0:dhcp" is injected in the cmdline handling.
> In this case "dhclient -4" is called. From the man page:
>        -4     Use the DHCPv4 protocol to obtain an IPv4 address and
> configuration parameters.  This is the default and cannot be combined with
> -6.
> 
> I am not sure, what dhclient does, but I was not assuming any IPv6 config
> was done by it. dracut itsself does no IPv6 for dhcp only for ip=dhcp6

Yes it is the other way round. In case of static ipv4 configuration dracut flushes ipv6 addresses autoconfigured by kernel, which does not happen for ip=<IFNAME>:dhcp.

Seems that neither dracut nor NM supports ipv6 ibft configuration.
The problem is how to make connection generated by NM ibft plugin and connection created in initramfs by ip=ibft match.
Comment 5 Radek Vykydal 2016-03-29 11:29:06 EDT
I think we should unify the behavior of ipv6 autoconfig in case of static and dynamic ipv4 (only) configuration in dracut and then use according ipv6 method (auto if dracut doesn't flush ipv6 addresses, ignore if it does) for ibft connection generated by NM.
Comment 6 Radek Vykydal 2016-03-30 08:05:12 EDT
Harald, what do you think about comment #4 and comment #5?
Can we unify ip=<iface>:dhcp to flush ipv6 autoconfigured addresses as well? Maybe it would be required also for dual stack configuration (bug 1110540, https://github.com/dracutdevs/dracut/blob/master/TODO).
Comment 7 Radek Vykydal 2016-03-30 08:13:33 EDT
Dan, could we make the connections generated from iBFT default to ipv6.method = ignore so it would match with connection created by dracut for ip=ibft?
Comment 8 Radek Vykydal 2016-07-01 07:39:06 EDT
Based on email conversation with Harald and Dan, opening bug 1352005.

On 22.6.2016 09:50, Harald Hoyer wrote:
> On 21.06.2016 16:53, Dan Williams wrote:
>> On Tue, 2016-06-21 at 13:43 +0200, Radek Vykydal wrote:
>>> Hello Harald (and Dan),
>>>
>>> I am pinging for info on bug
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1309661
>>>
>>> I'd like to unify behavior of static ipv4 ibft configuration in
>>> initramfs and NM ibft plugin so that the connection created in
>>> initramfs
>>> is taken over after switchroot in installer by NM.
>>>
>>> The problem is described in the BZ, I'll try to summarize it here.
>>> The bug concerns static ipv4 ibft configuration, ipv4 dhcp works ok.
>>>
>>> 1) For ipv4 via dhcp (works ok):
>>>
>>> NM matches connection created in initramfs with what its ibft plugin
>>> finds in iBFT table:
>>> - based in iBFT table NM expects ipv6.method=auto
>>> - the existing (initramfs) connection it finds has ipv6.method=auto
>>> because of autoconfiguration created in initramfs by kernel.
>>>
>>> 2) For static ipv4 (doesn't work):
>>>
>>> NM does not match the connection created in initramfs
>>> - based on iBFT table it expects ipv6.method=auto
>>> - the existing (initramfs) connection it finds has
>>> ipv6.method=ignore
>>> because (for static ipv4) dracut flushes ipv6 adresses autocofigured
>>> by
>>> kernel
>>>
>>> I wonder if we could unify the behaviour by
>>> a) (https://bugzilla.redhat.com/show_bug.cgi?id=1309661#c6)
>>> - dracut flushing ipv6 addresses also in ipv4 dhcp case
>>> - NM expecting ipv6=ignore
>>> or
>>> b)
>>> - dracut not flushing ipv6 addresses in static ipv4 case
>>> - no change in NM - expects ipv6=auto
>>
>> Do we support iBFT IPv6 at all?  If we don't, then we could have the NM
>> iBFT plugin just always set ipv6.method=ignore and since Dracut flushes
>> the IPv6 addresses, everything should work?
>>
>> If we do, then a more complicated fix would be needed of course...
>>
>> Dan
>>
>
> Well, I am planning to add IPv6 support for iBFT.. But it's either
> IPv4 or IPv6 according to the format of
> /sys/firmware/ibft/ethernet<num>/ip-addr
>
> I guess dual stack static/dhcp settings are not possible for iBFT.
>
> So, here is my strategy:
> - if "ip=auto6" is present on the command line, set IPV6_AUTOCONF=yes.
> for every interface
> - iBFT, has either static/dhcp6 IPv6 or static/dhcp4 IPv4 (+auto6 in.
> case of ip=auto6)

mostly @Harald:

I am talking ipv4 *only* configuration here (no matter if via ip=ibft or.
just by device specific ip= options). The problem I hit is inconsistent.
dracut behavior regarding ipv6 addresses assigned to the device in.
initramfs.

for ip=ens3:dhcp
kernel autoconfigures ipv6 addresses => NM sees the connection as.
ipv6.method=auto

for ip=10.34.102.40::10.34.102.254:255.255.255.0::ens3:none
kernel autoconfigures ipv6 addresses *but* dracut flushes them in.
ifup.sh:do_static() => NM sees the connection as ipv6.method=ignore

I think there should be no difference in ipv6 device configuration for the

ip=ens3:dhcp
and
ip=10.34.102.40::10.34.102.254:255.255.255.0::ens3:none

Perhaps ifup.sh should flush addresses also for do_dhcp -4. Or am I.
missing some reason for the difference? (I can imagine unifying the.
behavior may be disruptive change for users at this point).

This inconsistence poses no real problem for Anaconda in normal.
(non-ibft) case, NM will just take over the connections created in.
initramfs and create according NM connection for them
- having ipv6.method=auto for ip=ens3:dhcp
- having ipv6.method=ignore for ip=<static config>:ens3:none

But for ip=ibft [1], NM is trying to match connection created from.
configuration found in iBFT (ignoring ipv6 now when ipv6 is not.
supported, just setting ipv6.method=auto I think) to the connection.
created in initramfs, and it can't use one value (ignore or auto) for.
both cases (static and dhcp), the matching would fail for one of the.
cases [2]. So with current dracut behaviour NM would have to set.
ipv6.method=auto for ipv4.method=auto and ipv6.method=ignore for.
ipv4.method=static which doesn't seem like a good way to fix the issue.
to me.


[1] which if I understand it correctly is translated by ibft_to_cmdline.
to static or dhcp ip= option similar as above
[2] and NM will create additional connection ("ibft0") to take over.
initramfs configuration instead of just using the connection created for.
the configuration found in iBFT ("iBFT ibft0")
Comment 10 Radek Vykydal 2016-08-31 07:54:15 EDT
https://github.com/rhinstaller/anaconda/pull/764
Comment 11 Radek Vykydal 2016-08-31 07:57:04 EDT
Due to bug 1371201 the problem is not limited just to static iBFT configuration but happens also for dhcp.

Also it concerns TUI as well (which should be also handled by PR from comment #10).
Comment 12 Radek Vykydal 2016-08-31 07:59:22 EDT
The patch in comment #10 is a solution for 7.3 where we do not seem to be able to fix it at deeper level (comment #8).
Comment 16 errata-xmlrpc 2016-11-03 19:22:12 EDT
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/RHEA-2016-2158.html

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