NetworkManager duplicates a connection after a NetworkManager restart if DHCP_HOSTNAME is defined

Updated -

When NetworkManager starts, if already configured network interfaces are present, it will try to match in place configurations with its connection configurations. When NetworkManager stops, it will try to avoid disrupting connectivity by leaving the network interfaces configured.

So, when NetworkManager is restarted, it will first stop, leaving the devices configured, and then it will start finding the same configured devices and trying to match them with its connection configurations.

Bugs BZ#1421082 and BZ#1421080 prevented NetworkManager connections with the ipv4.dhcp-hostname property set to be eligible in the matching process, causing NetworkManager to create a new in memory connection to track the configured device. The applied fix will let NetworkManager consider in the match also connections with the ipv4.dhcp-hostname property set, just ignoring it in the matching process.

As a consequence, if there are systems with unused (but valid) connection configurations for existing interfaces with the ipv4.dhcp-hostname property set, this could cause NetworkManager to enable them on restart if they match a running connection.

In this case, the host may also change its hostname to the value in the ipv4.dhcp-hostname property if all these three conditions are met:

  1. there is no static hostname set

  2. there is a connection for the main device (the one with a default route) in the ifcfg files that is valid but not used (possibly a forgotten and never-used configuration file) with the ipv4.dhcp-hostname property set

  3. when NM starts there is an in-memory connection matching the connection described in the point 2 but for the ipv4.dhcp-hostname property

If all of these points are met, then the connection described in 2 may assume the one found on startup and change the transient hostname to the one in the ipv4.dhcp-hostname property.

Note that connection in 2 can be applied regardless the connection.autoconnect value as it is assumed, not started.

To avoid the mentioned problems, please remove all unused connection with wrong ipv4.dhcp-hostname if any.