Network Manager tools (nmtui nmcli) fail to update the IP address on v9.5
This worked 100% on 9.4, however after upgrade to 9.5 this fails with an error message.
If I manually edit the interface config file for Network Manager, restart the service from the console and then ifdown/ifup the interface, then I can change the IP and other parameters.
I donât think that we can explain the message before we see it.
Is that nmcli con down $conn-name and nmcli con up $conn-name or some legacy scripts?
Which files, exactly?
Hi, I am so sorryâŚ
The nmtui error message on trying to change the IP Address under the interface Edit screen:
Error Message:
Unable to save connection: 802-3-ethernet.mac-address-denylist: unknown property
nmcli:
nmcli c modify ens33 ipv4.address 10.255.1.46
Error: Failed to modify connection âens33â: 802-3-ethernet.mac-address-denylist: unknown property
The NetworkManager interface config path:
/etc/NetworkManager/system-connection.
The config filename: ens33.nmconnection
Fascinating. The man nm-settings does list that property for me:
802-3-ethernet.mac-address
Alias: mac
If specified, this connection will only apply to the Ethernet device whose permanent MAC address matches. This property does not change the MAC address of the device (i.e. MAC spoofing).
Format: MAC address802-3-ethernet.mac-address-blacklist
If specified, this connection will never apply to the Ethernet device whose permanent MAC address matches an address in the list. Each MAC address is in the standard hex-digits-and-colons notation (00:11:22:33:44:55).
Format: list of MAC addresses802-3-ethernet.mac-address-denylist
If specified, this connection will never apply to the Ethernet device whose permanent MAC address matches an address in the list. Each MAC address is in the standard hex-digits-and-colons notation (00:11:22:33:44:55).
Format: list of MAC addresses
Curiously, the 802-3-ethernet.mac-address-blacklist and 802-3-ethernet.mac-address-denylist seem identical (but one is not alias of the other).
Configuring and managing networking | Red Hat Product Documentation does not mention either list.
I would start by removal of the offending property. Is it really necessary anyway?
I was adding/removing/changing the mac-address. It was only the ip-address that was being changed. In fact, I have never used the mac blacklist or the mac denylist. No entry was added to them.
This always worked with no issues in Rocky 9.4 and before. Only since Rocky 9.5 was installed has this problem been showing up.
However, that operation is most likely something like:
And it seemingly does now:
In other words, there is never âonly X to changeâ â the whole config has to be consistent at every step.
A point update is not always mere âadd propertiesâ. It can also change system to be more strict â usually in the name of security.
I would create new, âfreshâ, connections with nmcli and then wipe out the old ones.
There is not any array in the config named as either mac-black-list or mac-deny-list. There is no entry to edit and nothing was added.
Even the nmtui config editor tool does NOT list these entries.
Why not try it on your own system and see.|
[root@al9 ~]# nmcli con add con-name example ifname eno2 type ethernet ipv6.method disabled ip4 10.20.30.1/24
Connection 'example' (eba1e409-4b84-4ac6-aca0-a7f1eb667f5b) successfully added.
[root@al9 ~]# nmcli con mod example ip4 10.20.30.22/24
[root@al9 ~]#
[root@al9 ~]# cat /etc/NetworkManager/system-connections/example.nmconnection
[connection]
id=example
uuid=eba1e409-4b84-4ac6-aca0-a7f1eb667f5b
type=ethernet
interface-name=eno2
[ethernet]
[ipv4]
address1=10.20.30.1/24
address2=10.20.30.22/24
method=manual
[ipv6]
addr-gen-mode=default
method=disabled
[proxy]
Oops, the âip4â adds address. We want only one:
[root@al9 ~]# nmcli con mod example ipv4.address 10.20.30.33/24
[root@al9 ~]# cat /etc/NetworkManager/system-connections/example.nmconnection
[connection]
id=example
uuid=eba1e409-4b84-4ac6-aca0-a7f1eb667f5b
type=ethernet
interface-name=eno2
[ethernet]
[ipv4]
address1=10.20.30.33/24
method=manual
[ipv6]
addr-gen-mode=default
method=disabled
[proxy]
That is what I saw.
How about trying that with the nmtui tool. I only tried to use the nmcli because of an error shown in the nmtui tool
That is how it used to work under Rocky9.4 - I only get the error now with Rocky9.5 (Upgraded from Rocky 9.4).
Trying to make sure the blacklist is empty, then gives an error that the mac-denylist variable does not exist.
typing:
nmcli c show ens33 | grep list, only shows the mac-blocklist variable.
There is something broken in the command line tools, as if an old library was used when it was compiled.
My config file is:
cat /etc/NetworkManager/system-connections/ens33.nmconnection
[connection]
id=ens33
uuid=6ec6c696-04f9-30c2-ae18-5a7190807575
type=ethernet
autoconnect-priority=-999
interface-name=ens33
timestamp=1739862592
[ethernet]
[ipv4]
address1=10.255.1.44/24,10.255.1.250
dns=41.208.60.189;196.30.224.60;
dns-search=cnbbw.co.za;
may-fail=false
method=manual
[ipv6]
addr-gen-mode=default
method=disabled
[proxy]
I have found the problem - When Rocky9.4 is upgraded to Rocky9.5, the latest version of NetworkManager is not installed. I had to manually upgrade NetworkManager and NetworkManager-tui to the latest version, and then it started working as expected after the Service was restarted.
That would suggest your system wasnât updated properly. If you do:
dnf update
then every single package updates, including Network Manager. It would suggest that some packages were only installed/updated manually rather than doing a full update.
That is exactly what I did to update it from 9.4 to 9.5
This has been the result of updating more than 10 systems, not only the one.
The dnf up should install all available updates.
If it did not, then either âallâ updates were not available (a broken mirror?)
or something did exclude some of the packages.
A version mismatch between tools. Some new (of 9.5) tools had the â802-3-ethernet.mac-address-denylistâ and some old (of 9.4) did not. The ensuing miscommunication between them produced the error.
Ideally, the package dependencies would be strict enough to prevent only some packages updating, but in practice having too many strict requirements is painful too.
You are welcome to install 9.4 on a system, and then update it to 9.5.
Iâve had 9.0 on my system, and itâs been upgraded through all versions to 9.5 without experiencing this problem. And all other systems Iâve done were 9.3 or 9.4 installs that also didnât have this problem. This would suggest the problem is with the way you configured the network on these machines previously with whatever settings you were choosing that are non-standard. Usually you just assign an IP address, subnet mask, default route, and DNS configuration. You mentioned doing other stuff, like changing MAC addresses, etc.
That is why nobody else has experienced this problem, and @jlehtone suggested for you to delete your network configurations and set them up as new ones due to the fact you applied non-standard settings that no doubt conflicted and caused your problems. Either that or what he said about the fact you had a mismatch of 9.4 or 9.5 packages that had feature conflicts. Which goes back to what I said before, that your system wasnât updated properly and had mixed 9.4 and 9.5 packages - although you said you did dnf update which cannot be the case, because if I do this, my systems update from 9.4 to 9.5 without mixing Network Manager packages like yours did. I donât need to try it, because Iâve updated plenty of systems and never experienced this.
Actually read what I said and an example of the config from the server I had just upgraded to 9.5 from 9.4 - I did not mention that I had configured or used anything MAC related, in fact I stated that the error message mentioned mac, even though I had set nothing at all with respect to the mac.
OK, so then that means it was down to what we already said - mix of 9.4 and 9.5 packages due to the fact the server wasnât updated properly.
That can only be presumed - no packages were ever upgraded by them selves, they were only ever upgraded, all at the same time.