RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1703960 - Device.Reapply() fails if wired setting have not been explicitly set
Summary: Device.Reapply() fails if wired setting have not been explicitly set
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.6
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-29 08:40 UTC by Edward Haas
Modified: 2020-03-31 20:08 UTC (History)
10 users (show)

Fixed In Version: NetworkManager-1.18.4-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-31 20:07:59 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
reproducer in python for ethernet device (1009 bytes, text/plain)
2019-10-21 12:20 UTC, Filip Pokryvka 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:1162 0 None None None 2020-03-31 20:08:37 UTC
freedesktop.org Gitlab NetworkManager/NetworkManager-ci/merge_requests/453/ 0 None None None 2019-10-23 13:21:53 UTC

Description Edward Haas 2019-04-29 08:40:07 UTC 
Description of problem:
While attempting to use `reapply` in the Nmstate project, we have found that in case the wired setting is not defined/added to the new profile, the reapply operation will fail, claiming that the mac address change is not supported.

`nm-device-error-quark: Can't reapply changes to '802-3-ethernet.cloned-mac-address' setting (3)`

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


How reproducible:


Steps to Reproduce:
1. Fetch existing profile using `get_connection_by_id`.
2. Create new profile using SimpleConnection.new()
3. Add to the new profile the wanted setting (connection and IPvX in our case) using `add_setting`. (do not include the wired setting)
4. Replace existing profile settings with the new profile setting using `replace_settings_from_connection(new_profile)`.
5. Commit the existing profile changes using `commit_changes_async`.
7. Execute reapply with the existing profile.

Actual results:
Step 7 fails with the following error:
`nm-device-error-quark: Can't reapply changes to '802-3-ethernet.cloned-mac-address' setting (3)`

Expected results:
Reapply should succeed because no wired changes have been requested.

Additional info:
Workaround: 
Fetching the wired setting from the current profile and using it in the new profile has resolved the problem.
Comment 2 Edward Haas 2019-04-29 08:41:52 UTC 
Seems like Device.Reapply() doesn't normalize input connection.
Comment 3 Beniamino Galvani 2019-05-25 16:20:33 UTC 
The root cause is that the ifcfg-rh settings plugin adds an empty wired setting when saving and reloading a bond/bridge/team connection. The patch at [1] should fix this issue.

[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/166
Comment 4 Beniamino Galvani 2019-06-03 08:34:14 UTC 
Fixed upstream by:

 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb5038defccfe02699f1eafd3ef505fe2aba2d27
Comment 7 Filip Pokryvka 2019-10-21 12:20:16 UTC 
Created attachment 1627660 [details]
reproducer in python for ethernet device

run these commands before python script:

nmcli con add type ethernet con-name testeth2 ifname eth2
nmcli device diconnect eth2
ip a add 192.168.5.5/24 dev eth2
Comment 8 Beniamino Galvani 2019-10-22 19:49:42 UTC 
(In reply to Filip Pokryvka from comment #7)
> Created attachment 1627660 [details]
> reproducer in python for ethernet device
> 
> run these commands before python script:
> 
> nmcli con add type ethernet con-name testeth2 ifname eth2
> nmcli device diconnect eth2
> ip a add 192.168.5.5/24 dev eth2

I tried this and the reapply fails with error:

  Can't reapply changes to '802-3-ethernet.mac-address' setting (3)

because the assumed connection on eth2 has ethernet.mac-address set while the new connection doesn't have it. NM computes the difference between the connection currently active and the one to reapply and finds that ethernet.mac-address changed, but that isn't a property that can be reapplied at runtime. This sounds correct in my opinion.
Comment 9 Filip Pokryvka 2019-10-23 13:21:54 UTC 
The reproducer above works for bond and non-assumed ethernet connections. Since assumed connections are special case, verifying the bug.
Comment 10 Edward Haas 2020-01-22 14:42:36 UTC 
Is this issue resolved? Why is the BZ still open?
Comment 11 Beniamino Galvani 2020-03-02 09:15:38 UTC 
(In reply to Edward Haas from comment #10)
> Is this issue resolved? Why is the BZ still open?

There are multiple issues related to reapplying an optional
setting.

The first one is that the wired setting was implicitly added by NM
when saving some connection types (bridges, bonds, etc.), and so if
you tried to reapply the same connection again without changes, NM
would complain because the new connection didn't have a wired setting
while the old one did. This issue was solved in this bz.

The other issue is that at the moment NM refuses to perform a reapply
if the new connection adds a wired setting with all default values (or
if it removes it and it was all defaults previously).

For the wired setting, a missing setting and one with all defaults is
equivalent; but this is not true for other settings. For example, a
missing sriov setting means not to touch SR-IOV related parameters;
while a sriov setting with default values (zero VFs) means to reset
VFs. So we need to implement a setting-specific comparison logic.
Comment 13 errata-xmlrpc 2020-03-31 20:07:59 UTC 
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://access.redhat.com/errata/RHBA-2020:1162
Note You need to log in before you can comment on or make changes to this bug.