update_ip4_config() and update_ip6_config() are called from nm_device_capture_initial_config().
At that point, we don't expect any activation-source scheduled, thus the "if" should not
not be hit anyway.
So, this patch should actually make no difference, but it seems clearer
to me. Also, because it would be a bug to re-schedule the idle handler
that is already pending, but from inspecting nm_device_capture_initial_config()
it is not immediately clear that this cannot be the case.
Make DHCPv6 more robust WRT temporary failures of servers by retrying
DHCP for a predefined number of times at regular intervals when the
lease expires.
https://bugzilla.gnome.org/show_bug.cgi?id=741347
Make DHCPv4 more robust WRT temporary failures of servers by retrying
DHCP for a predefined number of times at regular intervals when the
lease expires.
https://bugzilla.gnome.org/show_bug.cgi?id=741347
Introduce the nm_device_ip_method_failed() function to check if the
failure of an IP method should cause the activation to fail, and use
it where appropriate.
http://bugzilla.gnome.org/show_bug.cgi?id=741347
When a new dynamic configuration is received, it is stored in a member
of private structure (e.g. @dhcp6_ip6_config) and a commit is
scheduled. Before the commit is executed, an update_ipx_config() could
be called and it would change the configuration before it is
committed.
This race condition causes failures in assigning the addresses
received through DHCPv6 when the internal client is used (but
potentially other clients and methods are affected).
To fix it, postpone updates of IP configurations when a commit is
already pending.
The "source" field of NMPlatformIPRoute (now "rt_source") maps to the
protocol field of the route. The source of NMPlatformIPAddress (now
"addr_source") has no direct equivalent in the kernel.
As their use is different, they should have different names. Also,
the name "source" is used all over the place. Hence give the fields
a more distinct name.
The 'portname' sysfs attribute of s390 devices is deprecated since
kernel 4.4 and always set to 'no portname required'. But even on older
kernels such value must be interpreted as an unset portname and thus
ignored.
https://bugzilla.redhat.com/show_bug.cgi?id=1327204
Already previously, the mode and rc-manager were intertwined in a complicated
way:
- dns=none effectively disables rc-manager.
- if resolv.conf was immutable, it would disable the rc-manager
by setting "resolv_conf_mode=NM_DNS_MANAGER_RESOLV_CONF_UNMANAGED".
- resolv_conf_mode was anyway a redundant piece of information to
rc_manager.
Now there are only two relevant settings: priv->plugin and
priv->rc_manager. And they can be set independently from each other.
Before that was not possible. For example, you could not set a
dns plugin with rc-manager=unmanaged (the only way to achive that
was via an immutable resolv.conf or by having rc-manager=symlink
and let resolv.conf link somewhere else.
Generate a stable connection UUID for the default-wired-connection.
Otherwise, on every reboot, the UUID changes although the generated
connection is the same.
But also hash into the UUID the machine-id, the device name and the
hardware address. So, the UUID is only the same if the connection is
identical in every aspect.
Also, the UUID is used as Network_ID for the stable-privacy address
generation mode. It is bad to re-create different UUIDs on every boot
as it causes different addresses.
The infiniband drivers don't implement the rtnetlink link deletions.
Therefore we unrealize the NMDevice instance but the backing resources
stay around, preventing us from ever realizing the device again.
The device creation can be attempted if the name can be determined. It
alone is doesn't mean that there's a parent device -- the name could
just have been hardcoded in the connection.
NetworkManager[21519]: nm_device_get_ifindex: assertion 'NM_IS_DEVICE (self)' failed
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x5555557fb2e5 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd3d0) at gmessages.c:1046
1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 0x00007ffff4ec88c3 in g_logv (log_domain=0x5555557fb2e5 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd3d0) at gmessages.c:1046
#1 0x00007ffff4ec8a3f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1079
#2 0x00005555555d2090 in nm_device_get_ifindex (self=0x0) at devices/nm-device.c:562
#3 0x00005555555ef77a in nm_device_supports_vlans (self=0x0) at devices/nm-device.c:9865
#4 0x00005555555bf2f9 in create_and_realize (device=0x555555c549b0 [NMDeviceVlan], connection=0x555555b451e0, parent=0x0, out_plink=0x7fffffffd5f8, error=0x7fffffffd700) at devices/nm-device-vlan.c:225
#5 0x00005555555d5757 in nm_device_create_and_realize (self=0x555555c549b0 [NMDeviceVlan], connection=0x555555b451e0, parent=0x0, error=0x7fffffffd700) at devices/nm-device.c:1783
#6 0x0000555555688601 in system_create_virtual_device (self=0x555555af51c0 [NMManager], connection=0x555555b451e0) at nm-manager.c:1120
#7 0x000055555568894e in connection_changed (settings=0x555555ae8220 [NMSettings], connection=0x555555b451e0, manager=0x555555af51c0 [NMManager]) at nm-manager.c:1172
#8 0x0000555555693448 in nm_manager_start (self=0x555555af51c0 [NMManager], error=0x7fffffffda30) at nm-manager.c:4466
#9 0x00005555555d166f in main (argc=1, argv=0x7fffffffdba8) at main.c:454
(gdb)
Fixes: 332994f1b1
update_connection() may be called during startup when the bus watch
hasn't notified yet the presence (or absence) of the teamd service on
the bus. Try to obtain a connection to the service in order to
retrieve the current configuration.
If the connection specifies an interface name, it should never attach to
a device of a different name even if the factory thinks the connection
is compatible with the device.
This fixes an issue that caused the inifniband connections to attach to
different devices or partitions.
When we want to preserve the default-route on cleanup, we must first
set it to assumed, before clearing it. Otherwise, NMDefaultRouteManager's
update() will delete the default route.
This is the oposite of the deconfigure case, where we first set it to
!has && !assumed, to force the route-manager to delete the route.
Add a function _update_default_route() to set the default_route
flags and call update() in one step.
Also, if there are no changes, skip the call to NMDefaultRouteManager's
update().
The hardware address of a VLAN must be kept aligned with the one of
its parent device, and we already used a signal in NMDeviceVlan to
catch changes in parent address and update the VLAN device
accordingly.
But this didn't work in all cases because the change might happen
after the VLAN gets created but before we register the signal, so it
is necessary to add further checks to enforce the alignment during the
device activation.
https://bugzilla.redhat.com/show_bug.cgi?id=1325752
Currently, NM_CP_SIGNAL_CONNECTION_UPDATED signal will be invoked on an
idle handler. I want to change that, so to be save, delay actions that
matter on an idle handler.
This allows tests to use these functions on a different platform instance
then on the singleton. The change makes the argument list longer, which is
unfortunate. On the other hand, it makes those functions more useful
in general.
You can't have it all.
Also, they now follow the pattern of most functions in NM where the type
is a singleton: you always pass the singleton to the function, although
in the usual case there is only one singleton instance. This allows to
use the function also on the non-singleton instance.
In general we don't touch the externally set default route on devices
that use a generated-assumed connection. When the IP method is AUTO
(or DHCP), this means that we are not able to restore the default
route after a temporary expiration of the lease which removes
addresses/routes from the device.
Change this, and let NM update the default route for generated-assumed
devices using dynamic addressing.
https://bugzilla.redhat.com/show_bug.cgi?id=1265239
The applied connection must describe the configuration that was
initially activated on the device. Even if the IP configuration
changes, we shouldn't reset the applied connection for devices using a
generated-assumed connection, otherwise we would lose information on
the IP method we're trying on the device.
An externally configured software device is considered external-down until
it is IF_UP and has IP configuration.
When the user explicitly manages the device via UDEV rule, that decision
should overrule external-down.
For internal compilation we want to be able to use deprecated
API without warnings.
Define the version min/max macros to effectively disable deprecation
warnings.
However, don't do it via CFLAGS option in the makefiles, instead hack it
to "nm-default.h". After all, *every* source file that is for internal
compilation needs to include this header as first.
If the manager removes the device, the IP config objects must
be cleared. The reason is that NMPolicy registers to the IP config
changed signal and passes these object on to NMDnsManager.
If the INTERNAL_DEVICE_REMOVED signal is emited with IP configuration
object pending, those objects will be leaked.
This partly redoes commit f72816bf10,
which was reverted.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=764483
