DEVICE="ens3" ONBOOT=yes NETBOOT=yes UUID="23466771-f5fa-4ca9-856f-eaf4a8e20c3f" BOOTPROTO=none IPADDR="10.0.0.2" PREFIX="24" GATEWAY="10.0.0.1" HWADDR="52:54:00:12:34:56" TYPE=Ethernet NAME="ens3" This ifcfg file results in connection.interface-name=ens3. However, device-generated connection didn't set interface-name property. Fix that by setting interface-name property when generating a connection. Also allow matching connections if interface-name is not set in a connection. https://bugzilla.redhat.com/show_bug.cgi?id=1077743
When an existing connection profile has IPv6 method 'ignore', NM doesn't simply care about IPv6. Thus we should allow matching such a profile to devices with just a link-local address. The example can be a simple configuration like this: /etc/sysconfig/network-scripts/ifcfg-ens3: DEVICE="ens3" ONBOOT=yes NETBOOT=yes UUID="aa17d688-a38d-481d-888d-6d69cca781b8" BOOTPROTO=dhcp HWADDR="52:54:00:32:77:59" TYPE=Ethernet NAME="ens3" https://bugzilla.redhat.com/show_bug.cgi?id=1073824
If IPv4 configuration did not succeed or the device has no IPv4 addresses when NM restarts, it will detect the existing device configuration as 'disabled'. This can happen when a bridge has no slaves and thus cannot perform IPv4 addressing because it has no carrier (since bridge carrier status depends on slave carriers). When NM starts or restarts, it sees the bridge has no IPv4 address and assumes the IPv4 method is 'disabled'. This creates a new connection, which blocks any slave connections from activating if they specify their master via UUID (since the bridge's active connection is generated). Fix this by allowing matches from 'disabled' to 'auto' if the device has no carrier, and there are no other differences between the original and the candidate connections.
Refactor in preparation for some additional matching, and add testcases.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add versioned NM_DEPRECATED_IN_* and NM_AVAILABLE_IN_* macros, and tag new/deprecated functions accordingly. (All currently-deprecated functions are assumed to have been deprecated in 0.9.10.) Add NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED macros which can be set to determine which versions will cause warnings. With the current settings, external consumers of the libnm-util/libnm-glib APIs will have MIN_REQUIRED and MAX_ALLOWED both set to NM_VERSION_0_9_8 by default, meaning they will get warnings about functions added in 0.9.10. NM internally sets NM_VERSION_MAX_ALLOWED to NM_VERSION_NEXT_STABLE to ensure that it is always allowed to use all APIs.
Tag addresses and routes with their source. We'll use this later to do (or not do) operations based on where the item came from. One thing to note is that when synchronizing items with the kernel, all items are read as source=KERNEL even when they originally came from NetworkManager, since the kernel has no way of providing this source information. This requires the source 'priority', which nm_ip*_config_add_address() and nm_ip*_config_add_route() must respect to ensure that NM-owned routes don't have their source overwritten when merging various IP configs in ip*_config_merge_and_apply(). Also of note is that memcmp() can no longer be used to compare addresses/routes in nm-platform.c, but this had problems before anyway with ifindex, so that workaround from nm_platform_ip4_route_sync() can be removed. https://bugzilla.gnome.org/show_bug.cgi?id=722843 https://bugzilla.redhat.com/show_bug.cgi?id=1005416
Signed-off-by: Thomas Haller <thaller@redhat.com>
In the migration to NMPlatform, support for ptp/peer addresses was accidentally dropped. This broke OpenVPN configurations using 'p2p' topology, which send a different peer address than the local address for tunX, plus the server may also push routes that use the peer address as the next hop. NetworkManager was unable to add these routes, because the kernel had no idea how to talk to the peer, because the peer's address was not assigned to any interface or reachable over any routes. Partly based on a patch from Dan Williams.
If the interface who's IP configuration is being captured has the default route, then read DNS servers from resolv.conf into the NMIP[4|6]Config. This allows NetworkManager to repopulate resolv.conf if anything changes. For example, if the system does not define a persistent hostname, then when a device which has generated a connection activates, a hostname lookup will be performed. The results of that lookup may change resolv.conf, and thus NetworkManager must rewrite resolv.conf. Without capturing DNS information at startup when generating connections, an empty resolv.conf would be written.