Instead of telling a VPN service to quit, leave that up to the service
itself. Services based on libnm-glib-vpn already have a quit timeout
of 20 seconds. We also eventually want to D-Bus activate the VPN
services, and at that point we won't have a PID we can send signals
to.
CC nm-linux-platform.lo
platform/nm-linux-platform.c: In function '_nm_platform_link_get':
platform/nm-linux-platform.c:161:17: error: 'rtnllink' may be used uninitialized in this function [-Werror=maybe-uninitialized]
nl_object_put (*object);
^
platform/nm-linux-platform.c:1923:35: note: 'rtnllink' was declared here
auto_nl_object struct rtnl_link *rtnllink;
^
cc1: all warnings being treated as errors
Signed-off-by: Thomas Haller <thaller@redhat.com>
When only the lifetime of an address changes, we did not get a platform signal
as libnl does not consider the time fields in nl_object_diff().
Workaround by comparing the timestamps manually.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Moving setting the source of the address to the init_* functions.
This also has the advantage, that the platform internal to_string functions have the proper
source set.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Change the to_string functions to convert the lifetime/preferred values
to the time remaining when the function is evaluated. These functions
are used for printing/debugging, so it's more sensible to show the
remaining time.
On the other hand, for debugging, it's better to see the raw values (also).
In addition to the remaining time we keep to print the timestamps+now if the
address is not permanent. So when inspecting the logs it is possible to figure
out the real values.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Replace the calls to subtract_guint32() by _rebase_relative_time_on_now()
and _address_get_lifetime().
Signed-off-by: Thomas Haller <thaller@redhat.com>
The kernel tells the address lifetimes in the 'struct ifa_cacheinfo'
attribute. This contains two timestamps (cstamp and tstamp) and two
relative lifetimes (ifa_prefered and ifa_valid).
The timestamps are equal to clock_gettime(CLOCK_MONOTONIC) scale in
1/100th of a second (wrapping every 497 days).
The preferred/valid times are re-adjusted everytime when sending the
message and count down as the time goes by. In other words, they are
anchored relatively to the moment of when kernel creates the netlink
message.
As platform is caching the rtnl_addr object, the information of *when* the
lifetimes started counting is not available.
This patch fixes reading these values by hacking the libnl object
when it gets received, so that valid and preferred are instead absolute
expiration timestamps in scale nm_utils_get_monotonic_timestamp_s() --
which NM internally is used for address timestamps.
There are two minor downsides to this hack:
- the valid and preferred properties of a cached rtnl_addr object have
an unexpected meaning, i.e. they are absolute and in a different time
scale.
- later when converting rtnl_addr to NMPlatformIPAddress, the base
timestamp is set to "1", i.e. an NMPlatformIPAddress has no knowledge
of when the address was created or last modified. The timestamp
property of NMPlatformIPAddress is solely there to anchor the relative
timestamps lifetime and preferred. Do not use it for anything
else.
Another reason the timestamp property is meaningless is that
its scale nm_utils_get_monotonic_timestamp_s() starts counting at
process start. So addresses that existed before would have a negative
or zero timestamp, which we avoid. This in turn could be solved by either
allowing negative timestamps or by shifting
nm_utils_get_monotonic_timestamp_*(). Both is viable, but not
necessary (ATM), because the age of an address has no other apparent
use then to anchor the relative timestamps.
Another implication is, that we potentially could get rid of the
timestamp completely, and insteat make preferred and lifetime be
absolute expiries.
This will be fixed properly later, by not caching libnl objects but instead
native NMPlatform objects. For those we have full control over their properties.
https://bugzilla.gnome.org/show_bug.cgi?id=727382
Signed-off-by: Thomas Haller <thaller@redhat.com>
CC nm-manager.lo
nm-manager.c: In function 'assume_connection':
nm-manager.c:1605:345: error: 'return' with no value, in function returning non-void [-Werror=return-type]
g_return_if_fail (nm_device_get_state (device) >= NM_DEVICE_STATE_DISCONNECTED);
Minor error, introduced by commit f229f4e201.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When generating an NMConnection to match the current state of a
device, don't add its RA-provided and DHCP-provided routes to the
NMSettingIP4Config/NMSettingIP6Config, since those routes didn't come
from the connection profile before.
https://bugzilla.gnome.org/show_bug.cgi?id=729203
NMIP[46]Route had a "source" field, but it was always set to KERNEL
for routes read from the kernel (even if they were originally added by
NM).
Fix things a bit by translating between our "source" field and the
kernel's "protocol" field.
https://bugzilla.gnome.org/show_bug.cgi?id=729203
Instead of creating most routes with metric 0 and then fixing them
just before applying them, create the routes with the correct metric
in the first place (so that NMIP4Config and NMIP6Config don't have to
try to guess whether "metric 0" means "unset" or "actually metric 0").
If a link's "master" property changes unexpectedly (ie, from outside
NM), update the master and slave NMDevices to reflect it, without
making any changes to them.
The process of activating a slave requires that its master have an
NMActiveConnection. So don't allow generating a connection on a slave
until we have generated the connection on the master.
nm_device_generate_connection() was allowing connections for master
devices to have no IP config, but this didn't really make much sense,
since they would just fail at stage3 in that case anyway.
Now that we get multiple tries at generating a connection on a device,
we can just ignore the device until it has a proper connection.
If the initial attempt to assume a connection on a device fails, and
the device remains un-activated, but then something changes its
configuration externally, try to generate a new connection and assume
that.
If the IP config changes on a device that has assumed a generated
connection, then update the connection's NMSettingIP4Config /
NMSettingIP6Config, under the assumption that the configuration of
that device was in progress but incomplete when NM first observed it.
NMIP4Config and NMIP6Config had methods to update an existing
NMSetting. However, the functions would really only work correctly if
the passed-in setting was empty.
Change them from "update_setting" to "create_setting", and have them
create the NMSetting themselves, and update NMDevice for that.
(If we need update_setting later, we can add it, after figuring out
exactly how it's actually supposed to work.)
Some tests want to assert against the messages logged using g_test_expect_message().
In this mode, nmtst will not log anything itself.
Interpret the option no-expect-message which turns g_test_expect_message()
into a NOP and turns logging on. The use of this is for debugging such
tests, without asserting against the messages but printing them instead.
For tests that are not in the assert_message mode, the option has no
effect.
Example:
NMTST_DEBUG=debug,no-expect-message make -C src/settings/plugins/keyfile/tests/ check
Signed-off-by: Thomas Haller <thaller@redhat.com>
In tests nm-logging will directly write using g_log. Also, non-core components
use g_log() for logging. glib will not print messages with level
G_LOG_LEVEL_INFO or G_LOG_LEVEL_DEBUG unless G_MESSAGES_DEBUG is set.
When the user specifies NMTST_DEBUG turning on 'debug' or
'log-level=DEBUG' it can be reasonably assumed that he wants to see
debug messages. nmtst_init() now sets G_MESSAGES_DEBUG=all.
The user can disable this behaviour, by setting instead G_MESSAGES_DEBUG='',
because nmtst_init() will not reset an existing G_MESSAGES_DEBUG.
Signed-off-by: Thomas Haller <thaller@redhat.com>
In this mode, nmtst itself will not log anything and not set the logging
level. Also, it will set g_log_set_always_fatal().
This is for tests that want to assert against all logged messages via
g_test_expect_message().
In this mode also setting the logging level via NMTST_DEBUG variable has
no effect. The test is expected to manage the logging level itself and
changing the logging level might interfere with the test.
As a showcase, move keyfile/tests/test-keyfile.c to nmtst.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Call to nmtst_reexec_sudo(), which allows you to specify a program
via environment variable to exec the test.
This is useful to exec the test program with sudo.
NMTST_DEBUG="no-debug,sudo-cmd=$PWD/tools/test-sudo-wrapper.sh" make -C src/platform/tests/ check
Signed-off-by: Thomas Haller <thaller@redhat.com>
Always run the linux platform tests, even if called as non-root user.
In such a case, print a message and return 77 (signalizing that the test
was skipped).
Only if we configured with --enable-test=root, we enforce that the
user executes the tests as root.
Co-Authored-By: Pavel Šimerda <psimerda@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
In older versions of team (e.g. Fedora 17), the master team device
stays up, even if no slaves are IFF_LOWER_UP. Workaround this bug.
Signed-off-by: Thomas Haller <thaller@redhat.com>
In this case, the fake platform implementation was wrong in that it did
not set the source property of the route/address objects like linux
platform does. Fix the test and the fake platform.
https://bugzilla.gnome.org/show_bug.cgi?id=706293
Signed-off-by: Thomas Haller <thaller@redhat.com>
The handling for announcing links was broken resulting in
duplicate link-added signals from platform.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
When adding a link, the Linux platform implementation raises the
link-changed signal synchronously. Fix the fake platform to behave identically
and also fix all the tests.
This also fixes the Linux platform tests for the most part because now the
test functions (and fake platform) behave like the Linux system
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=706293
Co-Authored-By: Thomas Haller <thaller@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
