NMPolicy only updates the NMDnsManager's hostname when it changes,
which previously did not include at startup. Meaning if your hostname
never changed, NMDnsManager would never learn it (and so would never
add an appropriate "search" line to resolv.conf). Fix that.
This fixes automatic activation after changes in
commit ff7e47a418.
When a connection is deactivated impl_manager_deactivate_connection() is called
and the device goes to NM_DEVICE_STATE_DISCONNECTED. nm_device_state_changed()
then issues "state-changed" signal. The signal is connected to by various
listeners. The most interesting ones for this case are NMPolicy and
NMActiveConnection.
The problem is that NMPolicy's device_state_changed() is processed first and
thus in schedule_activate_check() we still have the old active connection
present (in ACTIVATED state).
This commit fixes the issue by connecting to "state-changed" signal using
g_signal_connect_after() in NMPolicy. This ensures NMPolicy's state-changed
handler is called after active connections are processed.
https://bugzilla.redhat.com/show_bug.cgi?id=1033187
Workaround a serious issue, that a connection that failed to activate
might retry to autoconnect indefinitly.
In NMPolicy, device_state_changed() decrements the retry count for
autoconnect. But immediatly it calls nm_connection_clear_secrets(),
which in turn triggers an NM_SETTINGS_SIGNAL_CONNECTION_UPDATED signal.
The problem is, that connection_updated() resets the try count again to
the default, and thus, the counter was effictivly not decremented.
For now, do not reset the retry count in connection_updated(). This
works arount the issue, but means, that when a user changes the
connection, it is not immediatly retried to autoconnect (as the intent
originally was). This will be fixed later.
https://bugzilla.redhat.com/show_bug.cgi?id=1040528
Signed-off-by: Thomas Haller <thaller@redhat.com>
When generating connections at startup for active interfaces, the
generation code may not always be able to read DNS information for
the connection. Thus, the device's IP4Config won't have any
nameservers and the device won't be considered for reverse-address
lookup. However, since any device that gets this far is already
the "best" device and has the default route, and thus should be the
one used for reverse-address lookup.
Second, reorganize the code better handle dual-stack in the
future by checking the IP configs directly, instead of the
devices. Since 'best4' and 'best6' may be different devices,
we want to operate on the IP configs, not devices, to handle
situations where the best IP4Config may not be suitable for
reverse lookup, but the best IP6Config is.
https://bugzilla.redhat.com/show_bug.cgi?id=1031763
These are (most likely) only warnings and not severe bugs.
Some of these changes are mostly made to get a clean run of
Coverity without any warnings.
Error found by running Coverity scan
https://bugzilla.redhat.com/show_bug.cgi?id=1025894
Co-Authored-By: Jiří Klimeš <jklimes@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Previously, ignore-carrier devices were always in the unavailable state
until they were activated. This required some complicated code to keep
track of whether the device was available or not based on what connections
existed, whether those connections were static-IP, and whether the device
was ignore-carrier. Various bits of the code used nm_device_can_activate()
for two different purposes: (1) to determine if the device was available
on an L2 basis, which nm_device_can_activate() wasn't well-suited to, and
(2) whether a specific connection could be activated at a given time
based on ignore-carrier and whether the connection was static IP or not.
Remove that complexity and confusion by making ignore-carrier devices
always move to DISCONNECTED state, and simply refuse to activate
connections that require connectivity, but allow connections that don't
require connectivity. Also, when the device has no carrier, don't
add connections that require connectivity to the AvailableConnections
device property.
Besides killing PendingActivation, this patch decouples ActiveConnection
creation from actually activating that connection. This allows the
ActiveConnection to complete authorization asynchronously. This will
also be used in the future for handling the DEACTIVATING state of devices
(for "pre-down" functionality).
ActiveConnections will (soon) not have a D-Bus path on creation, but
only when they are exported after authorization is complete. That
means we can't rely on their dbus path in the secondaries code.
Instead, track them directly since the path may be NULL.
Both NMActRequest and NMVPNConnection need to track their device's state,
so instead of both subclasses having to do so, consolidate that code into
the superclass.
nm_vpn_connection_get_ip6_internal_gateway might return NULL. In this
case, we add a device route (to gateway '::') over the vpn.
Before, in such a case, NM crashed with SEGFAULT.
https://bugzilla.redhat.com/show_bug.cgi?id=1019021
Signed-off-by: Thomas Haller <thaller@redhat.com>
If a VPN had the default route, :primary-connection would become NULL,
which is exactly what it's not supposed to do. Fix it to have the
value it's supposed to.
https://bugzilla.gnome.org/show_bug.cgi?id=710207
Although it's convenient in some places to have IP configs on all
connections, it makes more sense in other places to not have IP
configs on slaves. (eg, it's confusing for nmcli, etc, to report a
full NMSettingIP4Config on a slave device). So revert parts of the
earlier patch. However, it's still safe to assume that s_ip4 != NULL
if method != DISABLED, so some of the earlier simplifications can
stay.
Also, add nm_utils_get_ip_config_method(), which returns the correct
IP config method for a connection, whether the connection has IP4 and
IP6 settings objects or not, and use that to keep some more of the
simplifications from the earlier patch.
Make sure that all connections returned from NMSettings or created via
AddAndActivateConnection have an NMSettingIP4Config and an
NMSettingIP6Config, with non-NULL methods, and get rid of
now-unnecessary checks for those.
Also move the slaves-can't-have-IP-config checks into the
platform-independent code as well. This also gets rid of spurious
"ignoring IP4/IP6 configuration" warnings in ifcfg-rh when reading a
slave ifcfg file.
Partly based on a patch from Pavel.
https://bugzilla.gnome.org/show_bug.cgi?id=708875
When the IP[46]Config changes, a new configuration gets assembled.
Before, whenever the new configuration was different than the current
one, the IP[46]Config of the device was completely replaced. This also
meant, that the old dbus IP[46]Config object was removed and the new one
was exported.
Now instead of recreating a new configuration, it updates the existing
(already exported) configuration in-place.
Also, add new gobject properties 'gateway' and 'searches' to the config class,
they will be exported over dbus.
Also, whenever any of the exported properties changes, make sure that a
notify signal gets emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=707617
Signed-off-by: Thomas Haller <thaller@redhat.com>
The manager has already disposed of the ActiveConnections by the time
the Policy is disposed, but the manager wasn't clearing the
active_connections list, so the Policy got a stale list of freed
objects. Next, the manager wasn't always emitting ACTIVE_CONNECTION_REMOVED
when disposing of ActiveConnections, which the Policy listens to
for cleanup. This lead to warnings on shutdown when the Policy
attempted to clean up for already disposed objects
Fix all this by ensuring the Manager signals when removing
ActiveConnections, which the Policy then uses to clean up
it's stuff, and ensuring the manager properly cleans up its
ActiveConnection list.
Add properties to track the "primary" connection (ie, the active
connection with either the default route, or the route to the VPN with
the default route), and the active connection that is currently
activating, and likely to become the :primary-connection when it
completes.
https://bugzilla.gnome.org/show_bug.cgi?id=704841
Add a property on NMManager indicating that it is currently starting
up and activating startup-time/boot-time network connections.
"startup" is initially TRUE, and becomes FALSE once all NMDevices
report that they have no pending activity (eg, trying to activate,
waiting for a wifi scan to complete, etc). This is tracked via a new
NMDevice:has-pending-activity property, which is maintained partially
by the device itself, and partially by other parts of the code.
When a connection is removed from NMSettings, it gets deactivated. That was
happening once in response to the now-removed connection's visibility changing
to invisible to everyone, and a second time in response to the actual removal
signal. Unfortunately the second time the NMActiveConnection is already
cleaned up and in the DEACTIVATED state, and has no priv->device, which
causes great hilarity when nm_device_set_state() is called with NULL.
_deactivate_if_active() should only try to deactivate NMActiveConnections
that actually are active.
When a VPN wanted to add some routes (like the host route for the
VPN gateway) it would add them itself and listen for parent device
events and re-add them if necessary. That's pretty fragile, plus
the platform blows away routes that aren't part of the IP config
that's getting applied.
So we might as well just have the VPN connection tell the parent
what the routes are, and have the parent device handle updating
the routing. The routes are through the parent device anyway,
and so are "owned" by the parent too.
It appears the kernel does not send notifications via netlink if the
default route is removed in some cases. This causes the platform
route cache to become stale, and thus when the default route is
reset by NM the platform thinks the route already exists, and does
not add it. But the route doesn't exist, becuase the kernel silently
removed it without telling anyone.
Fix that with a big hammer by flushing/refilling the route cache when
devices are deactivated (deletion of their addresses causes the default
route to be removed by the kernel) and when the default route is
updated by NM itself.
Pavel: if we find a more granular method, we should probably revert
this as the cache refill can be expensive.
The previous ignore-carrier rules did not work well with dynamic IP
(dhcp/slaac) connections. Change the rule so that only static IP
connections can be activated when carrier is not present (but both
static and dynamic connections will remain up when carrier is lost).
Note that this patch doesn't effectively change any code.
Functions moved from nm-system:
* nm_system_apply_ip?_config → nm_ip?_config_commit
* ip?_dest_in_same_subnet → nm_ip?_config_destination_is_direct
Functions moved from NetworkManagerUtils:
* nm_utils_merge_ip?_config → nm_ip?_config_merge_setting
Functions renamed (and moved down to form one group):
* nm_ip?_config_new_for_interface → nm_ip?_config_capture
(The rationale for the rename is that from the achitectural point of
view it doesn't matter whether the function creates a new object or
updates an existing one. After the rename, it's obvious that
nm_ip?_config_capture() and nm_ip?_config_commit() are counterparts of
each other.)
nm_platform_*_sync() functions check the cached kernel configuration
items (addresses, routes) before adding addresses to the kernel.
Therefore we don't need to be so careful about pushing NetworkManager
configuration to the kernel.
This patch helps to avoid having to compare nm_ip[46]_config objects,
which should only be created when a configuration change is being
performed.
Allow devices to declare themselves unmanaged-by-default, but tweak
nm-manager and nm-policy to allow activating matching connections on
those devices anyway.
(This ensures that NM keeps its hands completely off the device unless
the user explicitly asks it to do something with it.)
Rather than passing specific bits of data to NMDHCPManager and
NMDnsManager, just let them call nm_config_get() and then get the data
themselves.
Also, remove the GError argument from nm_dhcp_manager_new(), since the
function never returned NULL. This in turn means there is no longer
any need for a distinction between nm_dhcp_manager_new() and
nm_dhcp_manager_get(), so remove the former.
Remove the HostnameThread stuff from nm-policy-hostname and just use
GResolver instead. Move the one remaining nm-policy-hostname function
into nm-policy.
"config-changed" signal is added to dns-manager and emited when resolv.conf is
changed. Policy listens for the signal and restarts reverse-lookup in order to
get correct results.
Various bits of code want the network interface which an IP config
came from, for example when distinguishing which interface to
send DNS requests to when the DNS servers are link-local. DNS
plugins may also want this data for various reasons.
So it makes sense to attach the interface name to the IP config
object when the DNS manager gets it, so that later DNS updates
that don't have any interface information (hostname changes, etc)
can still generate correct DNS information.
This also eliminates the "last_iface" hack, which was often
inaccurate.
It also now sends "NetworkManager" to SUSE netconfig as the
interface name, because the DNS information being sent is already
merged/prioritized and not specific to a network interface, so
it's time to stop lying about where it came from.
