Bug 1309661

(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?

(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

(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.

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.

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).

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?

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")

https://github.com/rhinstaller/anaconda/pull/764

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).

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).

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

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days