Created attachment 1591758 [details]
System logs with NM trace enabled

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/233

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?

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

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.

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

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

After bug 1734470 been fixed, this problem gone.

Closing