The original backport was different then what was done on master.
Make 'nm-config.c' more similar to what we have on master.
Fixes: d510f0a039
(cherry picked from commit 643f042b9b)
Code that is testable often needs special hooks to work
both for unit-tests and production.
Add a function nm_utils_get_testing() that returns whether
the code is run as part of a unit-test.
For non-testing mode, nm_utils_get_testing() will return
zero (NM_UTILS_TEST_NONE). For unit tests, the test should call
_nm_utils_set_testing() to configure tested functions.
By specifing the @flags attribute, the test can enable/disable
specific behaviors.
https://bugzilla.gnome.org/show_bug.cgi?id=701112
(cherry picked from commit b9d8dc050a)
keyfile should become our main import/export format. It is desirable,
that a keyfile can contain every aspect of a connection.
For blob certificates, the writer in core daemon would always write
them to a file and convert the scheme to path.
This behavior is not great for a (hyptetical) `nmcli connection export`
command because it would have to export them somehow outside of keyfile,
e.g. by writing them to temporary files.
Instead, if the write handler does not handle a certificate, use a
default implementation in nm_keyfile_write() which adds the blob inside
the keyfile.
Interestingly, keyfile reader already supported reading certificate
blobs. But this legacy format accepts the blob as arbitrary
binary without marking the format and without scheme prefix.
Instead of writing the binary data directly, write it with a new
uri scheme "data:;base64," and encode it in base64.
Also go through some lengths to make sure that whatever path
keyfile plugin writes, can be read back again. That is, because
keyfile writer preferably writes relative paths without prefix.
Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate
the detection of pathnames without file:// prefix and use it to
check whether the path name must be fully qualified.
(cherry picked from commit c9a8764ad2)
nm_keyfile_plugin_kf_get_integer_list() should always set
@length to zero when returning no integer list. So, this
is probably correct. Still, just to be explicit, anticipate
and handle a missing @tmp_list.
(cherry picked from commit f430774ca0)
We have nm_keyfile_plugin_utils_should_ignore_file() to ignore certain
files based on patterns. We also need a matching escape function to
avoid saving connections with a name we would ignore later.
https://bugzilla.gnome.org/show_bug.cgi?id=735824
(cherry picked from commit a823217b1f)
read_field() was supposed to set *error to NULL if there was no error,
but it missed one case. (If **current was '\0'.)
(cherry picked from commit d746103d75)
This gets called for all links via link_get_permanent_address(). This could
easily be an infiniband address and we don't want to assert it's not.
(cherry picked from commit 31c8bd6b69)
We ought to set an error if we're returning NULL from
connection_from_file_full(). Also, printing out a warning ourselves makes no
sense -- the caller communicates this if we signal an error by returning NULL.
(cherry picked from commit e27aa5b4d7)
When adding an IPv4 address, kernel will also add a device-route.
We don't want that route because it has the wrong metric. Instead,
we add our own route (with a different metric) and remove the
kernel-added one.
This could be avoided if kernel would support an IPv4 address flag
IFA_F_NOPREFIXROUTE like it does for IPv6 (see related bug rh#1221311).
One important thing is, that we want don't want to manage the
device-route on assumed devices. Note that this is correct behavior
if "assumed" means "do-not-touch".
If "assumed" means "seamlessly-takeover", then this is wrong.
Imagine we get a new DHCP address. In this case, we would not manage
the device-route on the assumed device. This cannot be fixed without
splitting unmanaged/assumed with related bug bgo 746440.
This is no regression as we would also not manage device-routes
for assumed devices previously.
We also don't want to remove the device-route if the user added
it externally. Note that here we behave wrongly too, because we
don't record externally added kernel routes in update_ip_config().
This still needs fixing.
Let IPv4 device-routes also be managed by NMRouteManager. NMRouteManager
has a list of all routes and can properly add, remove, and restore
the device route as needed.
One problem is, that the device-route does not get added immediately
with the address. It only appears some time later. This is solved
by NMRouteManager watching platform and if a matchin device-route shows up
within a short time after configuring addresses, remove it.
If the route appears after the short timeout, assume they were added for
other reasons (e.g. by the user) and don't remove them.
https://bugzilla.gnome.org/show_bug.cgi?id=751264https://bugzilla.redhat.com/show_bug.cgi?id=1211287
(cherry picked from commit 5f54a323d1)
When checking whether an address from platform should be deleted, we
compare the address with our list of @known_addresses.
For that we must also check for expired lifetimes, because
@known_addresses might contain expired addresses.
(cherry picked from commit 8336bd2a83)
Soon we will subscribe to the platform instance for change signals.
If a singleton instance uses another singleton instance, it should
keep a reference to it, especially if it subscribes to a signal
(that will be disconnected on dispose()).
(cherry picked from commit b79ade8975)
Also expose routes with "proto kernel". But add a flag
to nm_platform_ipx_route_get_all() to hide them by default.
(cherry picked from commit 42664e8752)
The previous version causes an unsigned integer underflow. That
is not wrong, but still change it.
Also use g_array_remove_index_fast() because the list of routes
is unsorted anyway.
(cherry picked from commit e7f3ccf7cd)
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)
