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.
(cherry picked from commit a47c13a7a2)
It can return NULL and makes Coverity upset:
CID 75369 (#1 of 1): Dereference null return value (NULL_RETURNS)
4. dereference: Dereferencing a null pointer ret.
(cherry picked from commit 76844c65d6)
For some device types, we use the DEVTYPE from sysfs to determine the
link type. However, the way we read from sysfs can race with device
renames and we could miss the chance to read DEVTYPE correctly.
This doesn't completely fix the sysfs race, but cures the boot-time race
with systemd renaming the device while we are initializing the link.
We ideally should use GUDev for all sysfs accesses, but that would need
some more work for this particular case as currently we need the link type
before we have an udev device instance.
https://bugzilla.gnome.org/show_bug.cgi?id=764803
Co-Authored-By: Beniamino Galvani <bgalvani@redhat.com>
(cherry picked from commit dd4d8b24da)
The notification was missing from a long time. The issue has been exposed only
now due to the c57e5a6b66 fix which properly
implemented the "startup-complete" notification substituting out of place code
which masked the bug.
(cherry picked from commit 19350c8975)
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
(cherry picked from commit 0589e659ca)
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.
(cherry picked from commit 89cf9429a7)
When mounting /proc with hidepid, we might fail to read the
start-time of the process from /proc/$PID/stat. In this case,
we should just accept a start-time of zero.
On the other side of authentication, polkit should accept a zero
start-time too.
nm_utils_get_start_time_for_pid() has other uses in NetworkManager,
mostly when killing a process from a PIDFILE or during
nm_utils_kill_process_sync(). In both these cases, this will only
succeed if we try to kill a process that also runs a root.
For processes started by the current instance, we don't care about the
PIDFILE and use nm_utils_kill_child_?sync() -- so there is no problem
with hidepid there.
https://bugzilla.gnome.org/show_bug.cgi?id=764502
(cherry picked from commit 3d505b3f87)
Pass an empty configuration file otherwise dnsmasq loads
"/etc/dnsmasq.conf".
We already allow for a config.d/ directory "/etc/NetworkManager/dnsmasq.d"
to allow the user to overwrite configuration. We don't want to consider
the global config file.
Fixes: 497a8aa5c6
(cherry picked from commit 3d3f71acec)
The 4 private fields pid, watch_id, progname and pidfile strictly
belong together. When spawning a child, we set all 4 of them and
when killing the child all get cleared. Cleanup to code to always
set those 4 fields together.
(cherry picked from commit 4d5ca7f9de)
When NetworkManager exits, it must preserve the DNS configuration of
devices that are left up.
Fixes: 9498ea507e
(cherry picked from commit 2158d6a5a8)
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.
(cherry picked from commit a93807c288)
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
(cherry picked from commit 03584e420f)
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.
(cherry picked from commit 332994f1b1)
...not from the connection. Otherwise the o.fdo.NM.openswan connection
would try to use a name they're not allowed to use.
(cherry picked from commit 178c972fac)
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.
(cherry picked from commit 4697376f99)
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().
(cherry picked from commit b2f794fe1e)
We must preserve the default-route on shutdown.
Thus it must first be announced as "assumed", and only removed
in a second step.
Fixes: 9498ea507e
(cherry picked from commit 2079f8361c)
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
(cherry picked from commit a032ce72ea)
The stongswan charon_nm plugin doesn't send a gateway.
The logic was accidentally broken with GDBus port.
Fixes: 231b0390a5
(cherry picked from commit dd0e070844)
Since commit 44768f0311, we skip
exposing NMIPAddress instances with prefix zero. Now, that is
supported and we can remove the check.
(cherry picked from commit 420bd611fd)
When adding a link, set both NLM_F_CREATE and NLM_F_EXCL
flags.
`ip route add` and systemd-networkd sets NLM_F_EXCL too.
(cherry picked from commit 4bb76fb4c3)
Consider:
unshare -n
ip link add d0 type dummy
ip link add d1 type dummy
ip link set d0 up
ip link set d1 up
ip addr add 192.168.100.5/24 dev d0
ip addr add 192.168.101.5/24 dev d1
ip route add 192.168.200.0/24 via 192.168.100.1
ip monitor &
ip route change 192.168.200.0/24 via 192.168.101.1
#prints 192.168.200.0/24 via 192.168.101.1 dev d1
ip route show
#192.168.100.0/24 dev d0 proto kernel scope link src 192.168.100.5
#192.168.101.0/24 dev d1 proto kernel scope link src 192.168.101.5
#192.168.200.0/24 via 192.168.101.1 dev d1
Note that `ip route change` replaced the exising route. "Replaced" in this
case means: the previous route on device "d0" got removed and a new route
on "d1" was added. However, kernel only sent one RTM_NEWROUTE event, no
RTM_DELROUTE that notifies about this change.
We need to workaround that by re-synching the routes when we receive a
RTM_NEWROUTE notification.
(cherry picked from commit f8b2cadfc1)
We aim to keep the platform cache up-to-date only via the netlink
events. However, due to kernel shortcomings we often have to resync
by re-requesting the data, which especially for routes and addresses
means a full dump (as you cannot request only specific route/address
information).
Thus it makes sense to avoid expensive dumps whenever we can.
We schedule dumps via "delayed-actions" and that is already smart
so that muliple schedulings are combined. However, before requesting
a new dump, we clear the flag that indicates that a dump is scheduled.
Thus, while processing the result of of a dump, we would re-schedule
anew which can be necessary in some cases.
In certain cases, we don't require a full resync, when we are in the
middle of processing a dump, because that one dump will provide us
with the full picture. Thus, we can avoid scheduling a new dump if
- we already scheduled a delayed action
- we are in the middle or processing a dump.
This can now be checked via delayed_action_refresh_all_in_progress().
(cherry picked from commit ff8c82e7e1)
