Bug 1731142 - Still got IPv6 link local address for a short time after disabled IPv6 [NEEDINFO]
Summary: Still got IPv6 link local address for a short time after disabled IPv6
Keywords:
Status: POST
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.1
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: 8.1
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: nmstate-nm-prio
TreeView+ depends on / blocked
 
Reported: 2019-07-18 12:40 UTC by Gris Ge
Modified: 2019-08-20 04:57 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
bgalvani: needinfo? (fge)


Attachments (Terms of Use)
System logs with NM trace enabled (492.91 KB, text/plain)
2019-07-18 12:42 UTC, Gris Ge
no flags Details

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.


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