Bug 1731142

Summary: Still got IPv6 link local address for a short time after disabled IPv6
Product: Red Hat Enterprise Linux 8 Reporter: Gris Ge <fge>
Component: NetworkManagerAssignee: Beniamino Galvani <bgalvani>
Status: POST --- QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.1CC: atragler, bgalvani, fgiudici, lrintel, rkhan, sukulkar, thaller
Target Milestone: rcFlags: thaller: needinfo? (fge)
Target Release: 8.1   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1738136    
Attachments:
Description Flags
System logs with NM trace enabled none

Description Gris Ge 2019-07-18 12:40:47 UTC
Description of problem:
After disabled IPv6, when connection got activated, the interface will have
the IPv6 link local address for a short time.


Version-Release number of selected component (if applicable):
NetworkManager-1.20.0-0.3.el8.x86_64

How reproducible:
50%


Steps to Reproduce:
    * sudo dnf install http://people.redhat.com/fge/tmp/nmstate-0.0.8-0.20190718.577gita13cdae.el8.noarch.rpm http://people.redhat.com/fge/tmp/python3-libnmstate-0.0.8-0.20190718.577gita13cdae.el8.noarch.rpm
    * wget http://people.redhat.com/fge/tmp/ci_env && chmod +x ci_env
    * wget http://people.redhat.com/fge/tmp/eth1_disable_ipv6.yml
    * wget http://people.redhat.com/fge/tmp/eth1_enable_ipv6.yml
    * sudo ./ci_env
    * sudo nmstatectl set eth1_enable_ipv6.yml && sudo nmstatectl set eth1_disable_ipv6.yml


Actual results:
Got NmstateVerificationError. and got logs like:

    address: [{'ip': 'fe80::c357:470:9965:cb44', 'prefix-length': 64}]
    connection id: eth1
    connection state: <enum NM_ACTIVE_CONNECTION_STATE_ACTIVATED of type
+NM.ActiveConnectionState>
    ipv6 method: disabled



Expected results:

nmstatectl raise no error. No ipv6 address after activation.

Additional info:

Comment 1 Gris Ge 2019-07-18 12:42:37 UTC
Created attachment 1591758 [details]
System logs with NM trace enabled

Comment 3 Beniamino Galvani 2019-08-09 10:16:36 UTC
Hi Gris,

I think the problem is that when Reapply() returns, the IP6Config
D-Bus object still contains addresses, and nmstate builds the current
state reading the object; right?

If so, we could fix the issue by synchronizing the IPxConfig state
with platform before returning.

But then we have a similar problem if the current method, is for
example, 'disabled' and you call reapply with method 'manual'. In this
case, we only start the the IP configuration process and return when
no actual addresses are set. To fix this case as well, we need to
delay the D-Bus return until all the requested changes are in place;
but this might be more complex.

How does nmstate build the current state during the verification? Did you
see any issues similar to this one also for other IP methods?

Comment 4 Gris Ge 2019-08-12 12:46:06 UTC
(In reply to Beniamino Galvani from comment #3)
> Hi Gris,
> 
> I think the problem is that when Reapply() returns, the IP6Config
> D-Bus object still contains addresses, and nmstate builds the current
> state reading the object; right?

Yes. From `active_connection.get_ip6_config().get_addresses()`.

> 
> If so, we could fix the issue by synchronizing the IPxConfig state
> with platform before returning.
> 
> But then we have a similar problem if the current method, is for
> example, 'disabled' and you call reapply with method 'manual'. In this
> case, we only start the the IP configuration process and return when
> no actual addresses are set. To fix this case as well, we need to
> delay the D-Bus return until all the requested changes are in place;
> but this might be more complex.
> 
> How does nmstate build the current state during the verification? Did you
> see any issues similar to this one also for other IP methods?

Don't know, due to bug #1734470, we don't use reapply when IPv6 is enabled.

I haven't check whether full reactivation still have this problem or not.

Will update soon.

Comment 5 Beniamino Galvani 2019-08-13 13:41:36 UTC
Ok. The point is: when Reapply() returns there is not guarantee that the state requested is already applied. So, for example, if nmstate reapplies ipv4.method=static when it was disabled, no address is yet configured when Reapply() returns because the method only starts IP configuration on the interface.

If nmstate needs to wait that the state is applied, it should probably wait that the IP configuration changes as desidered. Or perhaps it should monitor the NM_ACTIVATION_STATE_FLAG_IP{4,6}_READY flags of the active-connection; but at the moment NM never clears them after they are set the first time, so this needs a change in NM.

Comment 8 Gris Ge 2019-10-28 07:55:20 UTC
> How does nmstate build the current state during the verification?

nmstate create a new NM client object using `NM.Client.new()` and then use `get_ip6_config()` of `NM.ActiveConnection`
for IPv6 information.


With full reactivation, no problem found.

Comment 9 Thomas Haller 2019-10-28 08:40:54 UTC
> Can we request this bug to be fixed in 8.1.z and 8.2?

See comment 5. It's not clear that this behaviour is a bug.

Compare to ActiveConnection, which does not wait for any IP addressing either. It merely creates the D-Bus object with interface "org.freedesktop.NetworkManager.Connection.Active". This represents the activation, but it does not say that the activation is already in a particular state. You have to wait for that yourself.

When you issue Reapply, the active connection object already exists. Whatever state change you expect, you need to wait for it yourself.

Or why not?