build_rtnl_addr() has two parameters "lifetime" and "preferred". Both
count from *now*.
Fix nmp_object_to_nl() to properly set these timestamps. This bug had
not real consequences, because the only place where we use
nmp_object_to_nl() the arguments are 0.
(cherry picked from commit d0ed4de104)
When ping is launched to check the connectivity to the gateway it may
return earlier than the given timeout in case of error. When this
happens we need to respawn it until the timeout is reached.
While at it, increase maximum timeout value to 600 seconds.
https://bugzilla.redhat.com/show_bug.cgi?id=1128581
(cherry picked from commit e86f8354a7)
When the platform link gets removed outside of NetworkManager, we would
unmanage the device first. By checking the device state reason
NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the
interface, as it is already gone.
This was not correct because we must at least stop the dhcp client.
Otherwise the dhclient process keeps running. That meant, if the device
reappeared later, we would start dhclient again. Then we would find the
PID of the still running instance in the pidfile and kill it only than.
Fix it by replacing the 'deconfigure' boolean by a tri-state
'cleanup_type'.
(cherry picked from commit 3b21738d9c)
We kill the process based on the PID from the pidfile. This can be
our own child process so we must use nm_utils_kill_child_sync()
instead of nm_utils_kill_process_sync().
(cherry picked from commit c61c71a168)
kill(pid,sig) can return success for zombie processes. This
caused nm_utils_kill_process_sync() to hang indefinitely.
Fix it by also checking the process state.
(cherry picked from commit 69c98a336e)
ip[46]_config_merge_and_apply() do assume the settings that are merged later in
override the previously set ones and not the other way around. Otherwise e.g. a
gateway address from DHCP could override what's set in the connection.
(cherry picked from commit c942a8c35b)
When the call to route_add() fails and the route is SOURCE_USER the
function must return an error.
Fixes: 62c652c352
(cherry picked from commit 7364d7f8f2)
On master, we added new symbols
nm_setting_connection_autoconnect_slaves_get_type()
nm_setting_connection_get_autoconnect_slaves()
in the libnm_1_2_0 section.
It is wrong to extend the linker section of a stable
release. When backporting the patch we must create a
new linker section.
Move the symbols to the libnm_1_0_4 section. Note that
master (1.1) also defines the symbol there, so that the
upgrade path works.
https://bugzilla.gnome.org/show_bug.cgi?id=751535
Fixes: 408b631673
Also rewrite resolv.conf if the configuration didn't actually change.
Especially, react on SIGUSR1 which does not reload the configuration but
only writes "resolv.conf".
https://bugzilla.redhat.com/show_bug.cgi?id=1062301
(cherry picked from commit 68f1203c7c)
Also react on SIGUSR1 and SIGUSR2, beside SIGHUP.
Only for SIGHUP actually reload the configuration from
disc. For the other signals only emit a config-changed
signal.
(cherry picked from commit caed15e082)
Since commit ab6548c621 ("device: better accept external IP
changes"), ipX_config_merge_and_apply() applies the configuration
static settings to an intermediate, initially empty configuration
(priv->con_ipX_config) instead of the composite configuration, and
thus the handling of ignore-auto-routes and ignore-auto-dns options
done in nm_ipX_config_merge_setting() has no effect.
Fix this by clearing the routes and the DNS information when needed
before merging static settings to the composite configuration.
Fixes: ab6548c621
(cherry picked from commit 79630c11e5)
Example:
$ nmcli con add type eth con-name profile ifname nosuch
$ nmcli con up profile
or
# ip link set eth0 down
$ nmcli con add type eth con-name my-eth0 ifname eth0
$ nmcli con up my-eth0
Related to: 6fc3736c7a
(cherry picked from commit 02989896af)
When a master & slaves get activated at the same time, they all submit separate
active connections which race for the device after activation.
(cherry picked from commit 7a066a35ad)
If the device begins with "vlan", but a VLAN ID does not follow, the reader
would fail and ignore the actual VLAN_ID.
(cherry picked from commit f23a46d4b7)
The connection might not be exported on D-Bus at that point yet and thus shows
up as (null) in logs, which is not too helpful.
(cherry picked from commit edbf766e96)
