fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-01-04 01:40:16 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/nm-connectivity.h

85 lines
3.6 KiB
C
Raw Normal View History

core: add internet connectivity check * use libsoup to compare a http response from a given uri with a given response (use g_str_has_prefix () to compare) * do periodically check the connectivity. Check interval is configurable * check connectivity when device state change from/to NM_DEVICE_STATE_ACTIVATED
2011-10-21 21:21:30 +02:00
/* -*- Mode: C; tab-width: 4; indent-tabs-mode: t; c-basic-offset: 4 -*- */
/* NetworkManager -- Network link manager
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*
* Copyright (C) 2011 Thomas Bechtold <thomasbechtold@jpberlin.de>
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
* Copyright (C) 2017 Red Hat, Inc.
core: add internet connectivity check * use libsoup to compare a http response from a given uri with a given response (use g_str_has_prefix () to compare) * do periodically check the connectivity. Check interval is configurable * check connectivity when device state change from/to NM_DEVICE_STATE_ACTIVATED
2011-10-21 21:21:30 +02:00
*/
all: fix up multiple-include-guard defines Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include guard, which meant that nm-test-utils.h could not tell which of them was being included (and so, eg, if you tried to include nm-ip4-config.h in a libnm test, it would fail to compile because nm-test-utils.h was referring to symbols in src/nm-ip4-config.h). Fix this by changing the include guards in the non-API-stable parts of the tree: - libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H - libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__ - src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__ And likewise for all other headers. The two non-"nm"-prefixed headers, libnm/NetworkManager.h and src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and __NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely consistent with the general scheme, do still mostly make sense in isolation.
2014-08-13 14:10:11 -04:00
#ifndef __NETWORKMANAGER_CONNECTIVITY_H__
#define __NETWORKMANAGER_CONNECTIVITY_H__
core: add internet connectivity check * use libsoup to compare a http response from a given uri with a given response (use g_str_has_prefix () to compare) * do periodically check the connectivity. Check interval is configurable * check connectivity when device state change from/to NM_DEVICE_STATE_ACTIVATED
2011-10-21 21:21:30 +02:00
libnm: rename NetworkManager.h and NetworkManagerVPN.h "NetworkManager.h"'s name (and non-standard capitalization) suggest that it's some sort of high-level super-important header, but it's really just low-level D-Bus stuff. Rename it to "nm-dbus-interface.h" and likewise "NetworkManagerVPN.h" to "nm-vpn-dbus-interface.h"
2014-07-05 16:23:30 -04:00
#include "nm-dbus-interface.h"
core: add internet connectivity check * use libsoup to compare a http response from a given uri with a given response (use g_str_has_prefix () to compare) * do periodically check the connectivity. Check interval is configurable * check connectivity when device state change from/to NM_DEVICE_STATE_ACTIVATED
2011-10-21 21:21:30 +02:00
libnm: add nm_connectivity_state_cmp() helper
2018-12-03 10:27:06 +01:00
/*****************************************************************************/
static inline int
nm_connectivity_state_cmp (NMConnectivityState a, NMConnectivityState b)
{
if (a == NM_CONNECTIVITY_PORTAL && b == NM_CONNECTIVITY_LIMITED)
return 1;
if (b == NM_CONNECTIVITY_PORTAL && a == NM_CONNECTIVITY_LIMITED)
return -1;
NM_CMP_DIRECT (a, b);
return 0;
}
/*****************************************************************************/
connectivity: fix crash when removing easy-handle from curl callback libcurl does not allow removing easy-handles from within a curl callback. That was already partly avoided for one handle alone. That is, when a handle completed inside a libcurl callback, it would only invoke the callback, but not yet delete it. However, that is not enough, because from within a callback another handle can be cancelled, leading to the removal of (the other) handle and a crash: ==24572== at 0x40319AB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==24572== by 0x52DDAE5: Curl_close (url.c:392) ==24572== by 0x52EC02C: curl_easy_cleanup (easy.c:825) ==24572== by 0x5FDCD2: cb_data_free (nm-connectivity.c:215) ==24572== by 0x5FF6DE: nm_connectivity_check_cancel (nm-connectivity.c:585) ==24572== by 0x55F7F9: concheck_handle_complete (nm-device.c:2601) ==24572== by 0x574C12: concheck_cb (nm-device.c:2725) ==24572== by 0x5FD887: cb_data_invoke_callback (nm-connectivity.c:167) ==24572== by 0x5FD959: easy_header_cb (nm-connectivity.c:435) ==24572== by 0x52D73CB: chop_write (sendf.c:612) ==24572== by 0x52D73CB: Curl_client_write (sendf.c:668) ==24572== by 0x52D54ED: Curl_http_readwrite_headers (http.c:3904) ==24572== by 0x52E9EA7: readwrite_data (transfer.c:548) ==24572== by 0x52E9EA7: Curl_readwrite (transfer.c:1161) ==24572== by 0x52F4193: multi_runsingle (multi.c:1915) ==24572== by 0x52F5531: multi_socket (multi.c:2607) ==24572== by 0x52F5804: curl_multi_socket_action (multi.c:2771) Fix that, by never invoking any callbacks when we are inside a libcurl callback. Instead, the handle is marked for completion and queued. Later, we complete all queue handles separately. While at it, drop the @error argument from NMConnectivityCheckCallback. It was only used to signal cancellation. Let's instead signal that via status NM_CONNECTIVITY_CANCELLED. https://bugzilla.gnome.org/show_bug.cgi?id=797136 https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1792745 https://bugzilla.opensuse.org/show_bug.cgi?id=1107197 https://github.com/NetworkManager/NetworkManager/pull/207 Fixes: d8a31794c8b9db243076ba0c24dfe6e496b78697
2018-09-17 11:08:15 +02:00
#define NM_CONNECTIVITY_ERROR ((NMConnectivityState) -1)
#define NM_CONNECTIVITY_FAKE ((NMConnectivityState) -2)
#define NM_CONNECTIVITY_CANCELLED ((NMConnectivityState) -3)
#define NM_CONNECTIVITY_DISPOSING ((NMConnectivityState) -4)
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
core: add internet connectivity check * use libsoup to compare a http response from a given uri with a given response (use g_str_has_prefix () to compare) * do periodically check the connectivity. Check interval is configurable * check connectivity when device state change from/to NM_DEVICE_STATE_ACTIVATED
2011-10-21 21:21:30 +02:00
#define NM_TYPE_CONNECTIVITY (nm_connectivity_get_type ())
#define NM_CONNECTIVITY(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), NM_TYPE_CONNECTIVITY, NMConnectivity))
#define NM_CONNECTIVITY_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), NM_TYPE_CONNECTIVITY, NMConnectivityClass))
#define NM_IS_CONNECTIVITY(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), NM_TYPE_CONNECTIVITY))
core: fix NM_IS_*_CLASS(klass) macros The argument is 'klass' not 'obj'.
2012-07-27 13:15:54 +02:00
#define NM_IS_CONNECTIVITY_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), NM_TYPE_CONNECTIVITY))
core: add internet connectivity check * use libsoup to compare a http response from a given uri with a given response (use g_str_has_prefix () to compare) * do periodically check the connectivity. Check interval is configurable * check connectivity when device state change from/to NM_DEVICE_STATE_ACTIVATED
2011-10-21 21:21:30 +02:00
#define NM_CONNECTIVITY_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), NM_TYPE_CONNECTIVITY, NMConnectivityClass))
connectivity: schedule connectivity timers per-device and probe for short outages It might happen, that connectivitiy is lost only for a moment and returns soon after. Based on that assumption, when we loose connectivity we want to have a probe interval where we check for returning connectivity more frequently. For that, we handle tracking of the timeouts per-device. The intervall shall start with 1 seconds, and double the interval time until the full interval is reached. Actually, due to the implementation, it's unlikely that we already perform the second check 1 second later. That is because commonly the first check returns before the one second timeout is reached and bumps the interval to 2 seconds right away. Also, we go through extra lengths so that manual connectivity check delay the periodic checks. By being more smart about that, we can reduce the number of connectivity checks, but still keeping the promise to check at least within the requested interval. The complexity of book keeping the timeouts is remarkable. But I think it is worth the effort and we should try hard to - have a connectivity state as accurate as possible. Clearly, connectivity checking means that we probing, so being more intelligent about timeout and backoff timers can result in a better connectivity state. The connectivity state is important because we use it for the default-route penaly and the GUI indicates bad connectivity. - be intelligent about avoiding redundant connectivity checks. While we want to check often to get an accurate connectivity state, we also want to minimize the number of HTTP requests, in case the connectivity is established and suppossedly stable. Also, perform connectivity checks in every state of the device. Even if a device is disconnected, it still might have connectivity, for example if the user externally adds an IP address on an unmanaged device. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-02-20 21:41:14 +01:00
#define NM_CONNECTIVITY_CONFIG_CHANGED "config-changed"
core: add internet connectivity check * use libsoup to compare a http response from a given uri with a given response (use g_str_has_prefix () to compare) * do periodically check the connectivity. Check interval is configurable * check connectivity when device state change from/to NM_DEVICE_STATE_ACTIVATED
2011-10-21 21:21:30 +02:00
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
typedef struct _NMConnectivityClass NMConnectivityClass;
core: add internet connectivity check * use libsoup to compare a http response from a given uri with a given response (use g_str_has_prefix () to compare) * do periodically check the connectivity. Check interval is configurable * check connectivity when device state change from/to NM_DEVICE_STATE_ACTIVATED
2011-10-21 21:21:30 +02:00
GType nm_connectivity_get_type (void);
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
NMConnectivity *nm_connectivity_get (void);
core: add internet connectivity check * use libsoup to compare a http response from a given uri with a given response (use g_str_has_prefix () to compare) * do periodically check the connectivity. Check interval is configurable * check connectivity when device state change from/to NM_DEVICE_STATE_ACTIVATED
2011-10-21 21:21:30 +02:00
core: make connectivity checking per-device This moves tracking of connectivity to NMDevice and makes the NMManager negotiate the best of known connectivity states of devices. The NMConnectivity singleton handles its own configuration and scheduling of the permission checks, but otherwise greatly simplifies it. This will be useful to determine correct metrics for multiple default routes depending on actual internet connectivity. The per-device connection checks is not yet exposed on the D-Bus, since they probably should be per-address-family as well.
2017-03-20 13:36:00 +00:00
const char *nm_connectivity_state_to_string (NMConnectivityState state);
core: add internet connectivity check * use libsoup to compare a http response from a given uri with a given response (use g_str_has_prefix () to compare) * do periodically check the connectivity. Check interval is configurable * check connectivity when device state change from/to NM_DEVICE_STATE_ACTIVATED
2011-10-21 21:21:30 +02:00
device: add default route penalty only if concheck is enabled If we don't have connection checking functionality just avoid adding a penalty to the defaut route of newly activated connections. (cherry picked from commit 2524a6f8528c6f7b013f1404452d3aa7e4e4ab39)
2017-05-03 18:05:44 +02:00
gboolean nm_connectivity_check_enabled (NMConnectivity *self);
core: add internet connectivity check * use libsoup to compare a http response from a given uri with a given response (use g_str_has_prefix () to compare) * do periodically check the connectivity. Check interval is configurable * check connectivity when device state change from/to NM_DEVICE_STATE_ACTIVATED
2011-10-21 21:21:30 +02:00
connectivity: schedule connectivity timers per-device and probe for short outages It might happen, that connectivitiy is lost only for a moment and returns soon after. Based on that assumption, when we loose connectivity we want to have a probe interval where we check for returning connectivity more frequently. For that, we handle tracking of the timeouts per-device. The intervall shall start with 1 seconds, and double the interval time until the full interval is reached. Actually, due to the implementation, it's unlikely that we already perform the second check 1 second later. That is because commonly the first check returns before the one second timeout is reached and bumps the interval to 2 seconds right away. Also, we go through extra lengths so that manual connectivity check delay the periodic checks. By being more smart about that, we can reduce the number of connectivity checks, but still keeping the promise to check at least within the requested interval. The complexity of book keeping the timeouts is remarkable. But I think it is worth the effort and we should try hard to - have a connectivity state as accurate as possible. Clearly, connectivity checking means that we probing, so being more intelligent about timeout and backoff timers can result in a better connectivity state. The connectivity state is important because we use it for the default-route penaly and the GUI indicates bad connectivity. - be intelligent about avoiding redundant connectivity checks. While we want to check often to get an accurate connectivity state, we also want to minimize the number of HTTP requests, in case the connectivity is established and suppossedly stable. Also, perform connectivity checks in every state of the device. Even if a device is disconnected, it still might have connectivity, for example if the user externally adds an IP address on an unmanaged device. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-02-20 21:41:14 +01:00
guint nm_connectivity_get_interval (NMConnectivity *self);
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
typedef struct _NMConnectivityCheckHandle NMConnectivityCheckHandle;
typedef void (*NMConnectivityCheckCallback) (NMConnectivity *self,
NMConnectivityCheckHandle *handle,
NMConnectivityState state,
gpointer user_data);
NMConnectivityCheckHandle *nm_connectivity_check_start (NMConnectivity *self,
connectivity: allow limiting the connectivity check to a specified AF Nothing changes practically, as the NMDevice still starts this with AF_UNSPEC. That is going to change in the following commit. The ugly part: priv->concheck_x[0] in few places. I believe we shouldn't be using union aliasing here, and instead of indexing the v4/v6 arrays by a boolean it should be an enum. I'm not fixing it here, but I eventually plan to if this gets an ACK.
2018-07-03 19:20:45 +02:00
int family,
connectivity: use systemd-resolved for resolving the check endpoint This allows us to use the correct DNS server for the particular interface independent of what the system resolver is configured to use. The ugly part: Unfortunately, it is not all that easy. The libc's libresolv.so API does not provide means for influencing neither interface nor name servers used for DNS resolving. Curl can also be compiled with c-ares resolver backend that does provide the necessary functionality, but it requires and extra library and the Linux distributions don't seem to enable it. (Fedora doesn't, which is a good sign we don't have an option of relying on it.) systemd-resolved does provide everything we need. If we take care to keep its congfiguration up to date, we can use it to do the resolving on a particular interface with that interface's DNS configuration. Great! There's one more problem: Curl doesn't provide callbacks for resolving host names. It doesn't, however, allow us to pass in the pre-resolved hostnames in form of an CURLOPT_RESOLVE(3) option. This means we have to parse the host name out of the URL ourselves. Fair enough I guess...
2017-06-22 16:46:13 +02:00
int ifindex,
connectivity: rework async connectivity check requests An asynchronous request should either be cancellable or not keep the target object alive. Preferably both. Otherwise, it is impossible to do a controlled shutdown when terminating NetworkManager. Currently, when NetworkManager is about to terminate, it just quits the mainloop and essentially leaks everything. That is a bug. If we ever want to fix that, every asynchronous request must be cancellable in a controlled way (or it must not prevent objects from getting disposed, where disposing the object automatically cancels the callback). Rework the asynchronous request for connectivity check to - return a handle that can be used to cancel the operation. Cancelling is optional. The caller may choose to ignore the handle because the asynchronous operation does not keep the target object alive. That means, it is still possible to shutdown, by everybody giving up their reference to the target object. In which case the callback will be invoked during dispose() of the target object. - also, the callback will always be invoked exactly once, and never synchronously from within the asynchronous start call. But during cancel(), the callback is invoked synchronously from within cancel(). Note that it's only allowed to cancel an action at most once, and never after the callback is invoked (also not from within the callback itself). - also, NMConnectivity already supports a fake handler, in case connectivity check is disabled via configuration. Hence, reuse the same code paths also when compiling without --enable-concheck. That means, instead of having #if WITH_CONCHECK at various callers, move them into NMConnectivity. The downside is, that if you build without concheck, there is a small overhead compared to before. The upside is, we reuse the same code paths when compiling with or without concheck. - also, the patch synchronizes the connecitivty states. For example, previously `nmcli networking connectivity check` would schedule requests in parallel, and return the accumulated result of the individual requests. However, the global connectivity state of the manager might have have been the same as the answer to the explicit connecitivity check, because while the answer for the manual check is waiting for all pending checks to complete, the global connectivity state could already change. That is just wrong. There are not multiple global connectivity states at the same time, there is just one. A manual connectivity check should have the meaning of ensure that the global state is up to date, but it still should return the global connectivity state -- not the answers for several connectivity checks issued in parallel. This is related to commit b799de281bc01073c31dd2c86171b29c8132441c (libnm: update property in the manager after connectivity check), which tries to address a similar problem client side. Similarly, each device has a connectivity state. While there might be several connectivity checks per device pending, whenever a check completes, it can update the per-device state (and return that device state as result), but the immediate answer of the individual check might not matter. This is especially the case, when a later request returns earlier and obsoletes all earlier requests. In that case, earlier requests return with the result of the currend devices connectivity state. This patch cleans up the internal API and gives a better defined behavior to the user (thus, the simple API which simplifies implementation for the caller). However, the implementation of getting this API right and properly handle cancel and destruction of the target object is more complicated and complex. But this but is not just for the sake of a nicer API. This fixes actual issues explained above. Also, get rid of GAsyncResult to track information about the pending request. Instead, allocate our own handle structure, which ends up to be nicer because it's strongly typed and has exactly the properties that are useful to track the request. Also, it gets rid of the awkward _finish() API by passing the relevant arguments to the callback directly.
2018-01-05 17:46:49 +01:00
const char *iface,
NMConnectivityCheckCallback callback,
gpointer user_data);
void nm_connectivity_check_cancel (NMConnectivityCheckHandle *handle);
all: fix up multiple-include-guard defines Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include guard, which meant that nm-test-utils.h could not tell which of them was being included (and so, eg, if you tried to include nm-ip4-config.h in a libnm test, it would fail to compile because nm-test-utils.h was referring to symbols in src/nm-ip4-config.h). Fix this by changing the include guards in the non-API-stable parts of the tree: - libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H - libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__ - src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__ And likewise for all other headers. The two non-"nm"-prefixed headers, libnm/NetworkManager.h and src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and __NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely consistent with the general scheme, do still mostly make sense in isolation.
2014-08-13 14:10:11 -04:00
#endif /* __NETWORKMANAGER_CONNECTIVITY_H__ */
Reference in a new issue Copy permalink