fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-05-17 19:18:07 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/nm-connectivity.c

1017 lines
30 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: connectivity check cleanups; check response headers too Clean up some memleaks and fix some possible lifecycle issues for strings. Also add a short-circuit check using the HTTP headers.
2011-12-05 14:48:47 -06:00
* Copyright (C) 2011 Dan Williams <dcbw@redhat.com>
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
* Copyright (C) 2016 - 2018 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: cleanup includes and let "nm-default.h" include "config.h" - All internal source files (except "examples", which are not internal) should include "config.h" first. As also all internal source files should include "nm-default.h", let "config.h" be included by "nm-default.h" and include "nm-default.h" as first in every source file. We already wanted to include "nm-default.h" before other headers because it might contains some fixes (like "nm-glib.h" compatibility) that is required first. - After including "nm-default.h", we optinally allow for including the corresponding header file for the source file at hand. The idea is to ensure that each header file is self contained. - Don't include "config.h" or "nm-default.h" in any header file (except "nm-sd-adapt.h"). Public headers anyway must not include these headers, and internal headers are never included after "nm-default.h", as of the first previous point. - Include all internal headers with quotes instead of angle brackets. In practice it doesn't matter, because in our public headers we must include other headers with angle brackets. As we use our public headers also to compile our interal source files, effectively the result must be the same. Still do it for consistency. - Except for <config.h> itself. Include it with angle brackets as suggested by https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
2016-02-19 14:57:48 +01:00
#include "nm-default.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
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
#include "nm-connectivity.h"
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
#include "nm-dbus-manager.h"
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
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
#include <string.h>
connectivity: always build nm-connectivity.c source We already do conditional build with "#if WITH_CONCHECK". Get rid of the conditional in the makefile and instead do conditional compilating inside the source file "nm-connectivity.c". The advantage is, now if you want to know which parts are build, you only need to grep for the WITH_CONCHECK preprocessor define instead of also caring about the conditional in Makefile.am and meson.build. It doesn't change the fact of conditional compilation. But it consistently uses one mechanism to achieve it.
2018-02-19 19:50:18 +01:00
#if WITH_CONCHECK
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
#include <curl/curl.h>
connectivity: always build nm-connectivity.c source We already do conditional build with "#if WITH_CONCHECK". Get rid of the conditional in the makefile and instead do conditional compilating inside the source file "nm-connectivity.c". The advantage is, now if you want to know which parts are build, you only need to grep for the WITH_CONCHECK preprocessor define instead of also caring about the conditional in Makefile.am and meson.build. It doesn't change the fact of conditional compilation. But it consistently uses one mechanism to achieve it.
2018-02-19 19:50:18 +01:00
#endif
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
shared: drop duplicate c-list.h header Use the one from the project just imported.
2018-04-06 16:40:23 +02:00
#include "c-list/src/c-list.h"
connectivity: use default on missing connectivity.interval config Manual page claims that a missing configuration option for connectivity interval means "300". That was not the case for a long time (never?). https://bugzilla.gnome.org/show_bug.cgi?id=723350 Based-on-patch-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com>
2015-02-19 14:24:37 +01:00
#include "nm-config.h"
connectivity: implement nm_connectivity_state_to_string() as NM_UTILS_LOOKUP_STR_DEFINE_WARN()
2016-02-01 13:32:02 +01:00
#include "NetworkManagerUtils.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
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
#define HEADER_STATUS_ONLINE "X-NetworkManager-Status: online\r\n"
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
/*****************************************************************************/
core: clean up and simplify connectivity check We can just use property notifications instead of having a separate connected signal. Also clean up some formatting and make some private variable names shorter.
2011-12-13 17:35:36 -06:00
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
NM_UTILS_LOOKUP_STR_DEFINE_STATIC (_state_to_string, int /*NMConnectivityState*/,
connectivity/trivial: move code nm_connectivity_state_to_string() is entirely independent of the GObject implementation of NMConnectivity. Move it to the beginning of the source file. It will be useful next because we will *always* build "nm-connectivity.c" source file, but disable various parts with #if. Hence, move the part that should always be build to the top.
2018-02-19 19:47:26 +01:00
NM_UTILS_LOOKUP_DEFAULT_WARN ("???"),
NM_UTILS_LOOKUP_STR_ITEM (NM_CONNECTIVITY_UNKNOWN, "UNKNOWN"),
NM_UTILS_LOOKUP_STR_ITEM (NM_CONNECTIVITY_NONE, "NONE"),
NM_UTILS_LOOKUP_STR_ITEM (NM_CONNECTIVITY_LIMITED, "LIMITED"),
NM_UTILS_LOOKUP_STR_ITEM (NM_CONNECTIVITY_PORTAL, "PORTAL"),
NM_UTILS_LOOKUP_STR_ITEM (NM_CONNECTIVITY_FULL, "FULL"),
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
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
NM_UTILS_LOOKUP_STR_ITEM (NM_CONNECTIVITY_ERROR, "ERROR"),
NM_UTILS_LOOKUP_STR_ITEM (NM_CONNECTIVITY_FAKE, "FAKE"),
NM_UTILS_LOOKUP_STR_ITEM (NM_CONNECTIVITY_CANCELLED, "CANCELLED"),
NM_UTILS_LOOKUP_STR_ITEM (NM_CONNECTIVITY_DISPOSING, "DISPOSING"),
connectivity/trivial: move code nm_connectivity_state_to_string() is entirely independent of the GObject implementation of NMConnectivity. Move it to the beginning of the source file. It will be useful next because we will *always* build "nm-connectivity.c" source file, but disable various parts with #if. Hence, move the part that should always be build to the top.
2018-02-19 19:47:26 +01:00
);
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 *
nm_connectivity_state_to_string (NMConnectivityState state)
{
return _state_to_string (state);
}
connectivity/trivial: move code nm_connectivity_state_to_string() is entirely independent of the GObject implementation of NMConnectivity. Move it to the beginning of the source file. It will be useful next because we will *always* build "nm-connectivity.c" source file, but disable various parts with #if. Hence, move the part that should always be build to the top.
2018-02-19 19:47:26 +01:00
/*****************************************************************************/
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
struct _NMConnectivityCheckHandle {
CList handles_lst;
NMConnectivity *self;
NMConnectivityCheckCallback callback;
gpointer user_data;
char *ifspec;
connectivity: add a unique counter for logging connectivity checks While at it, replace "AF_INET" with "IPv". The connectivity check logging line is already much too long. Save a few characters. Also, I think the meaning of "AF_INET" is less clear (to a novice user) than "IPv4".
2018-12-01 15:01:17 +01:00
const char *completed_log_message;
char *completed_log_message_free;
connectivity: always build nm-connectivity.c source We already do conditional build with "#if WITH_CONCHECK". Get rid of the conditional in the makefile and instead do conditional compilating inside the source file "nm-connectivity.c". The advantage is, now if you want to know which parts are build, you only need to grep for the WITH_CONCHECK preprocessor define instead of also caring about the conditional in Makefile.am and meson.build. It doesn't change the fact of conditional compilation. But it consistently uses one mechanism to achieve it.
2018-02-19 19:50:18 +01:00
#if WITH_CONCHECK
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
struct {
char *response;
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;
GCancellable *resolve_cancellable;
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
CURLM *curl_mhandle;
guint curl_timer;
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
CURL *curl_ehandle;
struct curl_slist *request_headers;
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
struct curl_slist *hosts;
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
GString *recv_msg;
} concheck;
#endif
connectivity: always build nm-connectivity.c source We already do conditional build with "#if WITH_CONCHECK". Get rid of the conditional in the makefile and instead do conditional compilating inside the source file "nm-connectivity.c". The advantage is, now if you want to know which parts are build, you only need to grep for the WITH_CONCHECK preprocessor define instead of also caring about the conditional in Makefile.am and meson.build. It doesn't change the fact of conditional compilation. But it consistently uses one mechanism to achieve it.
2018-02-19 19:50:18 +01:00
connectivity: add a unique counter for logging connectivity checks While at it, replace "AF_INET" with "IPv". The connectivity check logging line is already much too long. Save a few characters. Also, I think the meaning of "AF_INET" is less clear (to a novice user) than "IPv4".
2018-12-01 15:01:17 +01:00
guint64 request_counter;
connectivity: don't use GDBusProxy for resolving names via systemd-resolved
2018-12-01 14:22:19 +01:00
int addr_family;
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
core/trivial: move code
2018-01-05 15:52:39 +01:00
guint timeout_id;
connectivity: don't use GDBusProxy for resolving names via systemd-resolved
2018-12-01 14:22:19 +01:00
NMConnectivityState completed_state;
bool fail_reason_no_dbus_connection:1;
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/trivial: move code
2018-01-05 15:52:39 +01:00
enum {
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
CONFIG_CHANGED,
core/trivial: move code
2018-01-05 15:52:39 +01:00
LAST_SIGNAL
};
static guint signals[LAST_SIGNAL] = { 0 };
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
typedef struct {
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
CList handles_lst_head;
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
CList completed_handles_lst_head;
core: clean up and simplify connectivity check We can just use property notifications instead of having a separate connected signal. Also clean up some formatting and make some private variable names shorter.
2011-12-13 17:35:36 -06:00
char *uri;
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
char *host;
char *port;
core: clean up and simplify connectivity check We can just use property notifications instead of having a separate connected signal. Also clean up some formatting and make some private variable names shorter.
2011-12-13 17:35:36 -06:00
char *response;
config: add an API to disable connectivity check via internal config file. https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:19:54 +08:00
gboolean enabled;
core: clean up connectivity code a bit Remove some unnecessary comments and some unnecessary code. Fix indentation.
2013-07-29 09:42:44 -04:00
guint interval;
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
NMConfig *config;
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
} NMConnectivityPrivate;
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
struct _NMConnectivity {
GObject parent;
NMConnectivityPrivate _priv;
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
struct _NMConnectivityClass {
GObjectClass parent;
};
G_DEFINE_TYPE (NMConnectivity, nm_connectivity, G_TYPE_OBJECT)
#define NM_CONNECTIVITY_GET_PRIVATE(self) _NM_GET_PRIVATE (self, NMConnectivity, NM_IS_CONNECTIVITY)
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
NM_DEFINE_SINGLETON_GETTER (NMConnectivity, nm_connectivity_get, NM_TYPE_CONNECTIVITY);
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
/*****************************************************************************/
core: introduce default logging macros
2016-10-14 15:32:56 +02:00
#define _NMLOG_DOMAIN LOGD_CONCHECK
#define _NMLOG(level, ...) __NMLOG_DEFAULT (level, _NMLOG_DOMAIN, "connectivity", __VA_ARGS__)
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
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
#define _NMLOG2_DOMAIN LOGD_CONCHECK
#define _NMLOG2(level, ...) \
G_STMT_START { \
const NMLogLevel __level = (level); \
\
if (nm_logging_enabled (__level, _NMLOG2_DOMAIN)) { \
_nm_log (__level, _NMLOG2_DOMAIN, 0, \
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
(cb_data->ifspec ? &cb_data->ifspec[3] : NULL), \
NULL, \
connectivity: add a unique counter for logging connectivity checks While at it, replace "AF_INET" with "IPv". The connectivity check logging line is already much too long. Save a few characters. Also, I think the meaning of "AF_INET" is less clear (to a novice user) than "IPv4".
2018-12-01 15:01:17 +01:00
"connectivity: (%s,IPv%c,%"G_GUINT64_FORMAT") " \
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
_NM_UTILS_MACRO_FIRST (__VA_ARGS__), \
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
(cb_data->ifspec ? &cb_data->ifspec[3] : ""), \
connectivity: add a unique counter for logging connectivity checks While at it, replace "AF_INET" with "IPv". The connectivity check logging line is already much too long. Save a few characters. Also, I think the meaning of "AF_INET" is less clear (to a novice user) than "IPv4".
2018-12-01 15:01:17 +01:00
nm_utils_addr_family_to_char (cb_data->addr_family), \
cb_data->request_counter \
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
_NM_UTILS_MACRO_REST (__VA_ARGS__)); \
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
} \
} G_STMT_END
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
/*****************************************************************************/
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: split out the finish of the connectivity checking Factor out the conclusion of the connectivity check. This will allow us to finish the connectivity check on other occassions than a successful connection end. Most importantly on timeouts; but it will also allow us to short-circuit the check when we conclude it without reading the full response.
2017-03-22 15:18:37 +01:00
static void
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
cb_data_complete (NMConnectivityCheckHandle *cb_data,
NMConnectivityState state,
const char *log_message)
connectivity: split out the finish of the connectivity checking Factor out the conclusion of the connectivity check. This will allow us to finish the connectivity check on other occassions than a successful connection end. Most importantly on timeouts; but it will also allow us to short-circuit the check when we conclude it without reading the full response.
2017-03-22 15:18:37 +01:00
{
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
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
nm_assert (cb_data);
nm_assert (NM_IS_CONNECTIVITY (cb_data->self));
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
nm_assert (cb_data->callback);
nm_assert (state != NM_CONNECTIVITY_UNKNOWN);
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
nm_assert (log_message);
self = cb_data->self;
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
/* mark the handle as completing. After this point, nm_connectivity_check_cancel()
* is no longer possible. */
cb_data->self = NULL;
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
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
c_list_unlink_stale (&cb_data->handles_lst);
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
#if WITH_CONCHECK
if (cb_data->concheck.curl_ehandle) {
/* Contrary to what cURL manual claim it is *not* safe to remove
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
* the easy handle "at any moment"; specifically it's not safe to
* remove *any* handle from within a libcurl callback. That is
* why we queue completed handles in this case.
*
* cb_data_complete() is however only called *not* from within a
* libcurl callback. So, this is fine. */
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
curl_easy_setopt (cb_data->concheck.curl_ehandle, CURLOPT_WRITEFUNCTION, NULL);
curl_easy_setopt (cb_data->concheck.curl_ehandle, CURLOPT_WRITEDATA, NULL);
curl_easy_setopt (cb_data->concheck.curl_ehandle, CURLOPT_HEADERFUNCTION, NULL);
curl_easy_setopt (cb_data->concheck.curl_ehandle, CURLOPT_HEADERDATA, NULL);
curl_easy_setopt (cb_data->concheck.curl_ehandle, CURLOPT_PRIVATE, NULL);
curl_easy_setopt (cb_data->concheck.curl_ehandle, CURLOPT_HTTPHEADER, NULL);
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
curl_multi_remove_handle (cb_data->concheck.curl_mhandle,
cb_data->concheck.curl_ehandle);
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
curl_easy_cleanup (cb_data->concheck.curl_ehandle);
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
curl_multi_cleanup (cb_data->concheck.curl_mhandle);
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
curl_slist_free_all (cb_data->concheck.request_headers);
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
curl_slist_free_all (cb_data->concheck.hosts);
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
}
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
nm_clear_g_source (&cb_data->concheck.curl_timer);
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
nm_clear_g_cancellable (&cb_data->concheck.resolve_cancellable);
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
#endif
nm_clear_g_source (&cb_data->timeout_id);
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
_LOG2D ("check completed: %s; %s",
nm_connectivity_state_to_string (state),
log_message);
cb_data->callback (self,
cb_data,
state,
cb_data->user_data);
/* Note: self might be a danling pointer at this point. It must not be used
* after this point, and all callers must either take a reference first, or
* not use the self pointer too. */
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
#if WITH_CONCHECK
g_free (cb_data->concheck.response);
if (cb_data->concheck.recv_msg)
g_string_free (cb_data->concheck.recv_msg, TRUE);
#endif
connectivity: fix memory leak Fixes: 9d43869e473b47542520c807dace93a6f9520964
2017-07-19 22:13:57 +02:00
g_free (cb_data->ifspec);
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
if (cb_data->completed_log_message_free)
g_free (cb_data->completed_log_message_free);
core/trivial: rename internal structure
2018-01-05 16:02:05 +01:00
g_slice_free (NMConnectivityCheckHandle, cb_data);
connectivity: split out the finish of the connectivity checking Factor out the conclusion of the connectivity check. This will allow us to finish the connectivity check on other occassions than a successful connection end. Most importantly on timeouts; but it will also allow us to short-circuit the check when we conclude it without reading the full response.
2017-03-22 15:18:37 +01:00
}
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
/*****************************************************************************/
#if WITH_CONCHECK
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
static void
cb_data_queue_completed (NMConnectivityCheckHandle *cb_data,
NMConnectivityState state,
const char *log_message_static,
char *log_message_take /* take */)
{
nm_assert (cb_data);
nm_assert (NM_IS_CONNECTIVITY (cb_data->self));
nm_assert (state != NM_CONNECTIVITY_UNKNOWN);
nm_assert (log_message_static || log_message_take);
nm_assert (cb_data->completed_state == NM_CONNECTIVITY_UNKNOWN);
nm_assert (!cb_data->completed_log_message);
nm_assert (c_list_contains (&NM_CONNECTIVITY_GET_PRIVATE (cb_data->self)->handles_lst_head, &cb_data->handles_lst));
cb_data->completed_state = state;
cb_data->completed_log_message = log_message_static ?: log_message_take;
cb_data->completed_log_message_free = log_message_take;
c_list_unlink_stale (&cb_data->handles_lst);
c_list_link_tail (&NM_CONNECTIVITY_GET_PRIVATE (cb_data->self)->completed_handles_lst_head, &cb_data->handles_lst);
}
static void
_complete_queued (NMConnectivity *self)
{
NMConnectivity *self_keep_alive = NULL;
NMConnectivityPrivate *priv = NM_CONNECTIVITY_GET_PRIVATE (self);
NMConnectivityCheckHandle *cb_data;
while ((cb_data = c_list_first_entry (&priv->completed_handles_lst_head, NMConnectivityCheckHandle, handles_lst))) {
if (!self_keep_alive)
self_keep_alive = g_object_ref (self);
cb_data_complete (cb_data,
cb_data->completed_state,
cb_data->completed_log_message);
}
nm_g_object_unref (self_keep_alive);
}
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
static const char *
_check_handle_get_response (NMConnectivityCheckHandle *cb_data)
{
return cb_data->concheck.response ?: NM_CONFIG_DEFAULT_CONNECTIVITY_RESPONSE;
}
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
static gboolean
connectivity/trivial: rename local functions to avoid "curl" prefix Since this is "C" there are not namespaces and libraries commonly choose a particular name prefix for their symbols. In case of libcurl, that is "curl_". We should avoid using the same name prefix, and choose something distinct.
2018-07-24 15:02:33 +02:00
_con_curl_check_connectivity (CURLM *mhandle, int sockfd, int ev_bitmask)
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
{
core/trivial: rename internal structure
2018-01-05 16:02:05 +01:00
NMConnectivityCheckHandle *cb_data;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
CURLMsg *msg;
CURLcode eret;
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
int m_left;
connectivity: allow 204 (no content) as connectivity test If the user is requesting an empty response ("") as expected string, let the connectivity check succeed if we actually get a 204 HTTP response code (reporting a successful request but without content). This allows using e.g. Android's default URLs for the connectivity check purpose: [connectivity] uri=http://google.com/generate_204 interval=60 response= https://mail.gnome.org/archives/networkmanager-list/2018-February/msg00005.html
2018-02-08 21:28:02 +01:00
long response_code;
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
CURLMcode ret;
int running_handles;
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
gboolean success = TRUE;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
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
ret = curl_multi_socket_action (mhandle, sockfd, ev_bitmask, &running_handles);
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
if (ret != CURLM_OK) {
connectivity: improve curl error messages
2018-07-03 14:09:01 +02:00
_LOGD ("connectivity check failed: (%d) %s", ret, curl_easy_strerror (ret));
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
success = FALSE;
}
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
while ((msg = curl_multi_info_read (mhandle, &m_left))) {
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
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
if (msg->msg != CURLMSG_DONE)
continue;
/* Here we have completed a session. Check easy session result. */
connectivity: avoid compiler warning for argument of curl_easy_getinfo() libcurl employs some typechecking via "curl/typecheck-gcc.h". When compling with --enable-lto, compilation fails otherwise with: make[2]: Entering directory '/data/src/NetworkManager' CC src/src_libNetworkManager_la-nm-connectivity.lo CCLD src/libNetworkManager.la CCLD src/libNetworkManagerTest.la CCLD src/dhcp/tests/test-dhcp-dhclient src/nm-connectivity.c: In function 'curl_check_connectivity': src/nm-connectivity.c:147:10: error: call to '_curl_easy_getinfo_err_string' declared with attribute warning: curl_easy_getinfo expects a pointer to char * for this info [-Werror] eret = curl_easy_getinfo (msg->easy_handle, CURLINFO_PRIVATE, &cb_data); ^ lto1: all warnings being treated as errors lto-wrapper: fatal error: /usr/bin/gcc returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed
2017-05-12 09:37:42 +02:00
eret = curl_easy_getinfo (msg->easy_handle, CURLINFO_PRIVATE, (char **) &cb_data);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
if (eret != CURLE_OK) {
connectivity: improve curl error messages
2018-07-03 14:09:01 +02:00
_LOGD ("curl cannot extract cb_data for easy handle, skipping msg: (%d) %s",
eret, curl_easy_strerror (eret));
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
success = FALSE;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
continue;
}
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
nm_assert (cb_data);
nm_assert (NM_IS_CONNECTIVITY (cb_data->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
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
if (cb_data->completed_state != NM_CONNECTIVITY_UNKNOWN) {
/* callback was already invoked earlier. Nothing to do. */
continue;
}
if (msg->data.result != CURLE_OK) {
cb_data_queue_completed (cb_data,
NM_CONNECTIVITY_LIMITED,
NULL,
connectivity: improve curl error messages
2018-07-03 14:09:01 +02:00
g_strdup_printf ("check failed: (%d) %s",
msg->data.result,
curl_easy_strerror (msg->data.result)));
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
} else if ( !((_check_handle_get_response (cb_data))[0])
&& (curl_easy_getinfo (msg->easy_handle, CURLINFO_RESPONSE_CODE, &response_code) == CURLE_OK)
&& response_code == 204) {
/* If we got a 204 response code (no content) and we actually
* requested no content, report full connectivity. */
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
cb_data_queue_completed (cb_data,
NM_CONNECTIVITY_FULL,
"no content, as expected",
NULL);
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
} else {
/* If we get here, it means that easy_write_cb() didn't read enough
* bytes to be able to do a match, or that we were asking for no content
* (204 response code) and we actually got some. Either way, that is
* an indication of a captive portal */
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
cb_data_queue_completed (cb_data,
NM_CONNECTIVITY_PORTAL,
"unexpected short response",
NULL);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
}
}
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
/* if we return a failure, we don't know what went wrong. It's likely serious, because
* a failure here is not expected. Return FALSE, so that we stop polling the file descriptor.
* Worst case, this leaves the pending connectivity check unhandled, until our regular
* time-out kicks in. */
return success;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
}
static gboolean
connectivity/trivial: rename local functions to avoid "curl" prefix Since this is "C" there are not namespaces and libraries commonly choose a particular name prefix for their symbols. In case of libcurl, that is "curl_". We should avoid using the same name prefix, and choose something distinct.
2018-07-24 15:02:33 +02:00
_con_curl_timeout_cb (gpointer user_data)
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
{
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
NMConnectivityCheckHandle *cb_data = user_data;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
cb_data->concheck.curl_timer = 0;
_con_curl_check_connectivity (cb_data->concheck.curl_mhandle, CURL_SOCKET_TIMEOUT, 0);
_complete_queued (cb_data->self);
connectivity: cosmetic fixes
2017-03-22 18:48:58 +00:00
return G_SOURCE_REMOVE;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
}
static int
multi_timer_cb (CURLM *multi, long timeout_ms, void *userdata)
{
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
NMConnectivityCheckHandle *cb_data = userdata;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
nm_clear_g_source (&cb_data->concheck.curl_timer);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
if (timeout_ms != -1)
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
cb_data->concheck.curl_timer = g_timeout_add (timeout_ms, _con_curl_timeout_cb, cb_data);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
return 0;
}
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
typedef struct {
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
NMConnectivityCheckHandle *cb_data;
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
GIOChannel *ch;
/* this is a very simplistic weak-pointer. If ConCurlSockData gets
* destroyed, it will set *destroy_notify to TRUE.
*
* _con_curl_socketevent_cb() uses this to detect whether it can
* safely access @fdp after _con_curl_check_connectivity(). */
gboolean *destroy_notify;
guint ev;
} ConCurlSockData;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
static gboolean
connectivity/trivial: rename local functions to avoid "curl" prefix Since this is "C" there are not namespaces and libraries commonly choose a particular name prefix for their symbols. In case of libcurl, that is "curl_". We should avoid using the same name prefix, and choose something distinct.
2018-07-24 15:02:33 +02:00
_con_curl_socketevent_cb (GIOChannel *ch, GIOCondition condition, gpointer user_data)
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
{
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
ConCurlSockData *fdp = user_data;
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
NMConnectivityCheckHandle *cb_data = fdp->cb_data;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
int fd = g_io_channel_unix_get_fd (ch);
int action = 0;
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
gboolean fdp_destroyed = FALSE;
gboolean success;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
if (condition & G_IO_IN)
action |= CURL_CSELECT_IN;
if (condition & G_IO_OUT)
action |= CURL_CSELECT_OUT;
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
if (condition & G_IO_ERR)
action |= CURL_CSELECT_ERR;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
nm_assert (!fdp->destroy_notify);
fdp->destroy_notify = &fdp_destroyed;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
success = _con_curl_check_connectivity (cb_data->concheck.curl_mhandle, fd, action);
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
if (fdp_destroyed) {
/* hups. fdp got invalidated during _con_curl_check_connectivity(). That's fine,
* just don't touch it. */
} else {
nm_assert (fdp->destroy_notify == &fdp_destroyed);
fdp->destroy_notify = NULL;
if (!success)
fdp->ev = 0;
}
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
_complete_queued (cb_data->self);
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
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
return success ? G_SOURCE_CONTINUE : G_SOURCE_REMOVE;
}
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
static int
connectivity/trivial: rename socket argument in multi_socket_cb() callback "s" might be a good name for a temporary string. But here it's really a file descriptor. Call it "fd".
2018-07-24 15:34:10 +02:00
multi_socket_cb (CURL *e_handle, curl_socket_t fd, int what, void *userdata, void *socketp)
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
{
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
NMConnectivityCheckHandle *cb_data = userdata;
connectivity/trivial: rename local functions to avoid "curl" prefix Since this is "C" there are not namespaces and libraries commonly choose a particular name prefix for their symbols. In case of libcurl, that is "curl_". We should avoid using the same name prefix, and choose something distinct.
2018-07-24 15:02:33 +02:00
ConCurlSockData *fdp = socketp;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
GIOCondition condition = 0;
connectivity: add compile time check that "curl_socket_t" is a typedef to plain "int" On non-Windows, libcurl's "curl_socket_t" type is just a typedef for int. We rely on that, because we use it as file descriptor. Add a compile time check to ensure that.
2018-07-24 15:36:19 +02:00
(void) _NM_ENSURE_TYPE (int, fd);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
if (what == CURL_POLL_REMOVE) {
if (fdp) {
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
if (fdp->destroy_notify)
*fdp->destroy_notify = TRUE;
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
curl_multi_assign (cb_data->concheck.curl_mhandle, fd, NULL);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
nm_clear_g_source (&fdp->ev);
g_io_channel_unref (fdp->ch);
connectivity/trivial: rename local functions to avoid "curl" prefix Since this is "C" there are not namespaces and libraries commonly choose a particular name prefix for their symbols. In case of libcurl, that is "curl_". We should avoid using the same name prefix, and choose something distinct.
2018-07-24 15:02:33 +02:00
g_slice_free (ConCurlSockData, fdp);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
}
} else {
if (!fdp) {
connectivity/trivial: rename local functions to avoid "curl" prefix Since this is "C" there are not namespaces and libraries commonly choose a particular name prefix for their symbols. In case of libcurl, that is "curl_". We should avoid using the same name prefix, and choose something distinct.
2018-07-24 15:02:33 +02:00
fdp = g_slice_new0 (ConCurlSockData);
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
fdp->cb_data = cb_data;
connectivity/trivial: rename socket argument in multi_socket_cb() callback "s" might be a good name for a temporary string. But here it's really a file descriptor. Call it "fd".
2018-07-24 15:34:10 +02:00
fdp->ch = g_io_channel_unix_new (fd);
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
curl_multi_assign (cb_data->concheck.curl_mhandle, fd, fdp);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
} else
nm_clear_g_source (&fdp->ev);
connectivity: fix evaluating @what argument of CURLMOPT_SOCKETFUNCTION It's not a bitfields, it's documented to be an enum with 4 possible values.
2018-02-12 19:16:16 +01:00
if (what == CURL_POLL_IN)
condition = G_IO_IN;
else if (what == CURL_POLL_OUT)
condition = G_IO_OUT;
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
else if (what == CURL_POLL_INOUT)
connectivity: fix evaluating @what argument of CURLMOPT_SOCKETFUNCTION It's not a bitfields, it's documented to be an enum with 4 possible values.
2018-02-12 19:16:16 +01:00
condition = G_IO_IN | G_IO_OUT;
if (condition)
connectivity: avoid busy looping with connectivity-check failed It seems, curl_multi_socket_action() can fail with connectivity check failed: 4 where "4" means CURLM_INTERNAL_ERROR. When that happens, it also seems that the file descriptor may still have data to read, so the glib IO callback _con_curl_socketevent_cb() will be called in an endless loop. Thereby, keeping the CPU busy with doing nothing (useful). Workaround by disabling polling on the file descriptor when something goes wrong. Note that optimally we would cancel the affected connectivity-check right away. However, due to the design of libcurl's API, from within _con_curl_socketevent_cb() we don't know which connectivity-checks are affected by a failure on this file descriptor. So, all we can do is avoid polling on the (possibly) broken file descriptor. Note that we anyway always schedule a timeout of last resort for each check. Even if something goes very wrong, we will fail the check within 15 seconds. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
2018-07-24 15:24:50 +02:00
fdp->ev = g_io_add_watch (fdp->ch, condition, _con_curl_socketevent_cb, fdp);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
}
connectivity: cosmetic fixes
2017-03-22 18:48:58 +00:00
return CURLM_OK;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
}
static size_t
easy_header_cb (char *buffer, size_t size, size_t nitems, void *userdata)
{
core/trivial: rename internal structure
2018-01-05 16:02:05 +01:00
NMConnectivityCheckHandle *cb_data = userdata;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
size_t len = size * nitems;
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
if (cb_data->completed_state != NM_CONNECTIVITY_UNKNOWN) {
/* already completed. */
return 0;
}
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
if ( len >= sizeof (HEADER_STATUS_ONLINE) - 1
&& !g_ascii_strncasecmp (buffer, HEADER_STATUS_ONLINE, sizeof (HEADER_STATUS_ONLINE) - 1)) {
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
cb_data_queue_completed (cb_data,
NM_CONNECTIVITY_FULL,
"status header found",
NULL);
connectivity: conclude the check as soon as we see the magic header No need to read the rest of the reponse.
2017-03-22 15:28:06 +01:00
return 0;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
}
return len;
}
static size_t
easy_write_cb (void *buffer, size_t size, size_t nmemb, void *userdata)
{
core/trivial: rename internal structure
2018-01-05 16:02:05 +01:00
NMConnectivityCheckHandle *cb_data = userdata;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
size_t len = size * nmemb;
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
const char *response;
if (cb_data->completed_state != NM_CONNECTIVITY_UNKNOWN) {
/* already completed. */
return 0;
}
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
if (!cb_data->concheck.recv_msg)
cb_data->concheck.recv_msg = g_string_sized_new (len + 10);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
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
g_string_append_len (cb_data->concheck.recv_msg, buffer, len);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
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
response = _check_handle_get_response (cb_data);;
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
if ( response
&& cb_data->concheck.recv_msg->len >= strlen (response)) {
connectivity: conclude the check as soon as we see enough bytes No need to read the full response into memory.
2017-03-22 15:36:50 +01:00
/* We already have enough data -- check response */
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
if (g_str_has_prefix (cb_data->concheck.recv_msg->str, response)) {
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
cb_data_queue_completed (cb_data,
NM_CONNECTIVITY_FULL,
"expected response",
NULL);
connectivity: conclude the check as soon as we see enough bytes No need to read the full response into memory.
2017-03-22 15:36:50 +01:00
} else {
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
cb_data_queue_completed (cb_data,
NM_CONNECTIVITY_PORTAL,
"unexpected response",
NULL);
connectivity: conclude the check as soon as we see enough bytes No need to read the full response into memory.
2017-03-22 15:36:50 +01:00
}
return 0;
}
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
return len;
}
connectivity: fix the connectivity check timeout CURLOPT_CONNECTTIMEOUT or CURLOPT_TIMEOUT only make sense if libcurl is handling the I/O loop (the "easy" interface); we need to implement our own timeout.
2017-03-22 15:44:13 +01:00
static gboolean
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
_timeout_cb (gpointer user_data)
connectivity: fix the connectivity check timeout CURLOPT_CONNECTTIMEOUT or CURLOPT_TIMEOUT only make sense if libcurl is handling the I/O loop (the "easy" interface); we need to implement our own timeout.
2017-03-22 15:44:13 +01:00
{
core/trivial: rename internal structure
2018-01-05 16:02:05 +01:00
NMConnectivityCheckHandle *cb_data = user_data;
connectivity: fix the connectivity check timeout CURLOPT_CONNECTTIMEOUT or CURLOPT_TIMEOUT only make sense if libcurl is handling the I/O loop (the "easy" interface); we need to implement our own timeout.
2017-03-22 15:44:13 +01:00
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
nm_assert (NM_IS_CONNECTIVITY (cb_data->self));
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
nm_assert (c_list_contains (&NM_CONNECTIVITY_GET_PRIVATE (cb_data->self)->handles_lst_head, &cb_data->handles_lst));
connectivity: fix the connectivity check timeout CURLOPT_CONNECTTIMEOUT or CURLOPT_TIMEOUT only make sense if libcurl is handling the I/O loop (the "easy" interface); we need to implement our own timeout.
2017-03-22 15:44:13 +01:00
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
cb_data_complete (cb_data, NM_CONNECTIVITY_LIMITED, "timeout");
connectivity: fix the connectivity check timeout CURLOPT_CONNECTTIMEOUT or CURLOPT_TIMEOUT only make sense if libcurl is handling the I/O loop (the "easy" interface); we need to implement our own timeout.
2017-03-22 15:44:13 +01:00
return G_SOURCE_REMOVE;
}
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
#endif
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
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
static gboolean
_idle_cb (gpointer user_data)
core: clean up and simplify connectivity check We can just use property notifications instead of having a separate connected signal. Also clean up some formatting and make some private variable names shorter.
2011-12-13 17:35:36 -06:00
{
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
NMConnectivityCheckHandle *cb_data = user_data;
core: fix up connectivity state checks We want to start the connectivity checks when any device gets activated, and stop them when all devices get deactivated. We also want to make sure it's running if a device gets deactivated but other devices are still active. If multiple devices are activated and if the default device gets deactivated, the other device may become the default device and we'll need a connectivity check for that device since we can't do per-device checks yet. Also, if connectivity checking is enabled at compile-time but not enabled at runtime, the connectivity bits should always report "connected" to preserve previous behavior, and this code makes it clearer how that is handled.
2011-12-14 13:41:57 -06:00
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
nm_assert (NM_IS_CONNECTIVITY (cb_data->self));
nm_assert (c_list_contains (&NM_CONNECTIVITY_GET_PRIVATE (cb_data->self)->handles_lst_head, &cb_data->handles_lst));
core: fix up connectivity state checks We want to start the connectivity checks when any device gets activated, and stop them when all devices get deactivated. We also want to make sure it's running if a device gets deactivated but other devices are still active. If multiple devices are activated and if the default device gets deactivated, the other device may become the default device and we'll need a connectivity check for that device since we can't do per-device checks yet. Also, if connectivity checking is enabled at compile-time but not enabled at runtime, the connectivity bits should always report "connected" to preserve previous behavior, and this code makes it clearer how that is handled.
2011-12-14 13:41:57 -06:00
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
cb_data->timeout_id = 0;
if (!cb_data->ifspec) {
gs_free_error GError *error = NULL;
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
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
/* the invocation was with an invalid ifname. It is a fail. */
g_set_error (&error, NM_UTILS_ERROR, NM_UTILS_ERROR_INVALID_ARGUMENT,
"no interface specified for connectivity check");
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
cb_data_complete (cb_data, NM_CONNECTIVITY_ERROR, "missing interface");
connectivity: don't use GDBusProxy for resolving names via systemd-resolved
2018-12-01 14:22:19 +01:00
} else if (cb_data->fail_reason_no_dbus_connection) {
gs_free_error GError *error = NULL;
g_set_error (&error, NM_UTILS_ERROR, NM_UTILS_ERROR_INVALID_ARGUMENT,
"no D-Bus connection");
cb_data_complete (cb_data, NM_CONNECTIVITY_ERROR, "no D-Bus connection");
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
} else
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
cb_data_complete (cb_data, NM_CONNECTIVITY_FAKE, "fake result");
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
return G_SOURCE_REMOVE;
}
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
static void
do_curl_request (NMConnectivityCheckHandle *cb_data)
{
NMConnectivityPrivate *priv = NM_CONNECTIVITY_GET_PRIVATE (cb_data->self);
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
CURLM *mhandle;
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
CURL *ehandle;
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
long resolve;
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
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
mhandle = curl_multi_init ();
if (!mhandle) {
cb_data_complete (cb_data, NM_CONNECTIVITY_ERROR, "curl error");
return;
}
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
ehandle = curl_easy_init ();
if (!ehandle) {
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
curl_multi_cleanup (mhandle);
cb_data_complete (cb_data, NM_CONNECTIVITY_ERROR, "curl error");
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
return;
}
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
cb_data->concheck.response = g_strdup (priv->response);
cb_data->concheck.curl_mhandle = mhandle;
cb_data->concheck.curl_ehandle = ehandle;
cb_data->concheck.request_headers = curl_slist_append (NULL, "Connection: close");
cb_data->timeout_id = g_timeout_add_seconds (20, _timeout_cb, cb_data);
curl_multi_setopt (mhandle, CURLMOPT_SOCKETFUNCTION, multi_socket_cb);
curl_multi_setopt (mhandle, CURLMOPT_SOCKETDATA, cb_data);
curl_multi_setopt (mhandle, CURLMOPT_TIMERFUNCTION, multi_timer_cb);
curl_multi_setopt (mhandle, CURLMOPT_TIMERDATA, cb_data);
curl_multi_setopt (mhandle, CURLOPT_VERBOSE, 1);
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
switch (cb_data->addr_family) {
case AF_INET:
resolve = CURL_IPRESOLVE_V4;
break;
case AF_INET6:
resolve = CURL_IPRESOLVE_V6;
break;
case AF_UNSPEC:
resolve = CURL_IPRESOLVE_WHATEVER;
break;
default:
resolve = CURL_IPRESOLVE_WHATEVER;
g_warn_if_reached ();
}
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
curl_easy_setopt (ehandle, CURLOPT_URL, priv->uri);
curl_easy_setopt (ehandle, CURLOPT_WRITEFUNCTION, easy_write_cb);
curl_easy_setopt (ehandle, CURLOPT_WRITEDATA, cb_data);
curl_easy_setopt (ehandle, CURLOPT_HEADERFUNCTION, easy_header_cb);
curl_easy_setopt (ehandle, CURLOPT_HEADERDATA, cb_data);
curl_easy_setopt (ehandle, CURLOPT_PRIVATE, cb_data);
curl_easy_setopt (ehandle, CURLOPT_HTTPHEADER, cb_data->concheck.request_headers);
curl_easy_setopt (ehandle, CURLOPT_INTERFACE, cb_data->ifspec);
curl_easy_setopt (ehandle, CURLOPT_RESOLVE, cb_data->concheck.hosts);
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
curl_easy_setopt (ehandle, CURLOPT_IPRESOLVE, resolve);
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
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
curl_multi_add_handle (mhandle, ehandle);
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
}
static void
resolve_cb (GObject *object, GAsyncResult *res, gpointer user_data)
{
connectivity: don't use GDBusProxy for resolving names via systemd-resolved
2018-12-01 14:22:19 +01:00
NMConnectivityCheckHandle *cb_data;
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
NMConnectivity *self;
NMConnectivityPrivate *priv;
GVariant *result;
GVariant *addresses;
gsize no_addresses;
int ifindex;
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 addr_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
GVariant *address = NULL;
const guchar *address_buf;
gsize len = 0;
char str[INET6_ADDRSTRLEN + 1] = { 0, };
char *host;
gsize i;
gs_free_error GError *error = NULL;
connectivity: don't use GDBusProxy for resolving names via systemd-resolved
2018-12-01 14:22:19 +01:00
result = g_dbus_connection_call_finish (G_DBUS_CONNECTION (object), res, &error);
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
if (g_error_matches (error, G_IO_ERROR, G_IO_ERROR_CANCELLED))
return;
connectivity: don't use GDBusProxy for resolving names via systemd-resolved
2018-12-01 14:22:19 +01:00
cb_data = user_data;
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
self = cb_data->self;
priv = NM_CONNECTIVITY_GET_PRIVATE (self);
connectivity: don't use GDBusProxy for resolving names via systemd-resolved
2018-12-01 14:22:19 +01:00
g_clear_object (&cb_data->concheck.resolve_cancellable);
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
if (!result) {
/* Never mind. Just let do curl do its own resolving. */
_LOG2D ("can't resolve a name via systemd-resolved: %s", error->message);
do_curl_request (cb_data);
return;
}
addresses = g_variant_get_child_value (result, 0);
no_addresses = g_variant_n_children (addresses);
g_variant_unref (result);
for (i = 0; i < no_addresses; i++) {
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
g_variant_get_child (addresses, i, "(ii@ay)", &ifindex, &addr_family, &address);
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
address_buf = g_variant_get_fixed_array (address, &len, 1);
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
if ( (addr_family == AF_INET && len == sizeof (struct in_addr))
|| (addr_family == AF_INET6 && len == sizeof (struct in6_addr))) {
inet_ntop (addr_family, address_buf, str, sizeof (str));
host = g_strdup_printf ("%s:%s:%s", priv->host, priv->port ?: "80", str);
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
cb_data->concheck.hosts = curl_slist_append (cb_data->concheck.hosts, host);
_LOG2T ("adding '%s' to curl resolve list", host);
g_free (host);
}
g_variant_unref (address);
}
g_variant_unref (addresses);
do_curl_request (cb_data);
}
connectivity: don't use GDBusProxy for resolving names via systemd-resolved
2018-12-01 14:22:19 +01:00
#define SD_RESOLVED_DNS ((guint64) (1LL << 0))
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
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
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 addr_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)
{
NMConnectivityPrivate *priv;
NMConnectivityCheckHandle *cb_data;
connectivity: add a unique counter for logging connectivity checks While at it, replace "AF_INET" with "IPv". The connectivity check logging line is already much too long. Save a few characters. Also, I think the meaning of "AF_INET" is less clear (to a novice user) than "IPv4".
2018-12-01 15:01:17 +01:00
static guint64 request_counter = 0;
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
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
g_return_val_if_fail (NM_IS_CONNECTIVITY (self), NULL);
g_return_val_if_fail (callback, NULL);
priv = NM_CONNECTIVITY_GET_PRIVATE (self);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
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
cb_data = g_slice_new0 (NMConnectivityCheckHandle);
cb_data->self = self;
connectivity: add a unique counter for logging connectivity checks While at it, replace "AF_INET" with "IPv". The connectivity check logging line is already much too long. Save a few characters. Also, I think the meaning of "AF_INET" is less clear (to a novice user) than "IPv4".
2018-12-01 15:01:17 +01:00
cb_data->request_counter = ++request_counter;
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
c_list_link_tail (&priv->handles_lst_head, &cb_data->handles_lst);
cb_data->callback = callback;
cb_data->user_data = user_data;
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
cb_data->completed_state = NM_CONNECTIVITY_UNKNOWN;
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
cb_data->addr_family = addr_family;
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
if (iface)
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
cb_data->ifspec = g_strdup_printf ("if!%s", iface);
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
#if WITH_CONCHECK
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
if (iface && ifindex > 0 && priv->enabled && priv->host) {
connectivity: don't use GDBusProxy for resolving names via systemd-resolved
2018-12-01 14:22:19 +01:00
GDBusConnection *dbus_connection;
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
cb_data->concheck.ifindex = ifindex;
connectivity: don't use GDBusProxy for resolving names via systemd-resolved
2018-12-01 14:22:19 +01:00
dbus_connection = nm_dbus_manager_get_dbus_connection (nm_dbus_manager_get ());
if (!dbus_connection) {
/* we have no D-Bus connection? That might happen in configure and quit mode.
*
* Anyway, something is very odd, just fail connectivity check. */
_LOG2D ("start fake request (fail due to no D-Bus connection)");
cb_data->fail_reason_no_dbus_connection = TRUE;
cb_data->timeout_id = g_idle_add (_idle_cb, cb_data);
return cb_data;
}
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
cb_data->concheck.resolve_cancellable = g_cancellable_new ();
connectivity: don't use GDBusProxy for resolving names via systemd-resolved
2018-12-01 14:22:19 +01:00
g_dbus_connection_call (nm_dbus_manager_get_dbus_connection (nm_dbus_manager_get ()),
"org.freedesktop.resolve1",
"/org/freedesktop/resolve1",
"org.freedesktop.resolve1.Manager",
"ResolveHostname",
g_variant_new ("(isit)",
(gint32) cb_data->concheck.ifindex,
priv->host,
(gint32) cb_data->addr_family,
SD_RESOLVED_DNS),
G_VARIANT_TYPE ("(a(iiay)st)"),
G_DBUS_CALL_FLAGS_NONE,
-1,
cb_data->concheck.resolve_cancellable,
resolve_cb,
cb_data);
_LOG2D ("start request to '%s' (try resolving '%s' using systemd-resolved)",
priv->uri,
priv->host);
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
return cb_data;
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
}
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
#endif
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
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
_LOG2D ("start fake request");
cb_data->timeout_id = g_idle_add (_idle_cb, cb_data);
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
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
return cb_data;
core: clean up and simplify connectivity check We can just use property notifications instead of having a separate connected signal. Also clean up some formatting and make some private variable names shorter.
2011-12-13 17:35:36 -06: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
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
void
nm_connectivity_check_cancel (NMConnectivityCheckHandle *cb_data)
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
{
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
g_return_if_fail (cb_data);
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
g_return_if_fail (NM_IS_CONNECTIVITY (cb_data->self));
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
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
nm_assert ( c_list_contains (&NM_CONNECTIVITY_GET_PRIVATE (cb_data->self)->handles_lst_head, &cb_data->handles_lst)
|| c_list_contains (&NM_CONNECTIVITY_GET_PRIVATE (cb_data->self)->completed_handles_lst_head, &cb_data->handles_lst));
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
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
cb_data_complete (cb_data, NM_CONNECTIVITY_CANCELLED, "cancelled");
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04:00
}
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
/*****************************************************************************/
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.
2017-05-03 18:05:44 +02:00
gboolean
nm_connectivity_check_enabled (NMConnectivity *self)
{
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
g_return_val_if_fail (NM_IS_CONNECTIVITY (self), FALSE);
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.
2017-05-03 18:05:44 +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
return NM_CONNECTIVITY_GET_PRIVATE (self)->enabled;
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.
2017-05-03 18:05:44 +02:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
core: improve NMManager:state transitions with connectivity checking The connectivity-checking code would generally result in NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE in the case where the connectivity check failed. The brief incorrect CONNECTED_GLOBAL is bad, because clients might see it and do the wrong thing. Instead, when we are ready to switch from CONNECTING to CONNECTED_*, do a connectivity check first, and switch to either CONNECTED_SITE or CONNECTED_GLOBAL based on the result of that.
2013-07-31 09:14:39 -04: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)
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
return nm_connectivity_check_enabled (self)
? NM_CONNECTIVITY_GET_PRIVATE (self)->interval
: 0;
core: clean up and simplify connectivity check We can just use property notifications instead of having a separate connected signal. Also clean up some formatting and make some private variable names shorter.
2011-12-13 17:35:36 -06: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
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
static gboolean
host_and_port_from_uri (const char *uri, char **host, char **port)
{
const char *p = uri;
const char *host_begin = NULL;
size_t host_len = 0;
const char *port_begin = NULL;
size_t port_len = 0;
/* scheme */
while (*p != ':' && *p != '/') {
if (!*p++)
return FALSE;
}
/* :// */
if (*p++ != ':')
return FALSE;
if (*p++ != '/')
return FALSE;
if (*p++ != '/')
return FALSE;
/* host */
if (*p == '[')
return FALSE;
host_begin = p;
while (*p && *p != ':' && *p != '/') {
host_len++;
p++;
}
if (host_len == 0)
return FALSE;
*host = strndup (host_begin, host_len);
/* port */
if (*p++ == ':') {
port_begin = p;
while (*p && *p != '/') {
port_len++;
p++;
}
if (port_len)
*port = strndup (port_begin, port_len);
}
return TRUE;
}
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
static 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
update_config (NMConnectivity *self, NMConfigData *config_data)
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
{
NMConnectivityPrivate *priv = NM_CONNECTIVITY_GET_PRIVATE (self);
connectivity: refactor handling parameters of NMConnectivity Currently the three parameters for the connectivity check (uri, interval, response) don't get reset. Soon they might be modified at any time when reloading the configuration. When calling the asynchronous HTTP connectivity check, we want to preserve the original parameters so that the result callback still can access them later. Pass the uri and response parameter on as ConCheckCbData.
2014-07-14 13:40:30 +02:00
const char *uri, *response;
guint interval;
config: add an API to disable connectivity check via internal config file. https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:19:54 +08:00
gboolean enabled;
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
gboolean changed = FALSE;
/* Set the URI. */
uri = nm_config_data_get_connectivity_uri (config_data);
if (uri && !*uri)
uri = NULL;
changed = g_strcmp0 (uri, priv->uri) != 0;
if (uri) {
char *scheme = g_uri_parse_scheme (uri);
if (!scheme) {
_LOGE ("invalid URI '%s' for connectivity check.", uri);
uri = NULL;
} else if (strcasecmp (scheme, "https") == 0) {
_LOGW ("use of HTTPS for connectivity checking is not reliable and is discouraged (URI: %s)", uri);
} else if (strcasecmp (scheme, "http") != 0) {
connectivity: downgrade verbosity of error logging Such failures during connectivity checks, may happen frequently and due to external causes. Don't log with error level to avoid spamming the logfile.
2018-07-11 15:55:06 +02:00
_LOGE ("scheme of '%s' uri doesn't use a scheme that is allowed for connectivity check.", uri);
connectivity: refactor handling parameters of NMConnectivity Currently the three parameters for the connectivity check (uri, interval, response) don't get reset. Soon they might be modified at any time when reloading the configuration. When calling the asynchronous HTTP connectivity check, we want to preserve the original parameters so that the result callback still can access them later. Pass the uri and response parameter on as ConCheckCbData.
2014-07-14 13:40:30 +02:00
uri = NULL;
}
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
if (scheme)
g_free (scheme);
}
if (changed) {
g_free (priv->uri);
priv->uri = g_strdup (uri);
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
g_clear_pointer (&priv->host, g_free);
g_clear_pointer (&priv->port, g_free);
connectivity: fix crash when the uri gets cleared from configuration host_and_port_from_uri() crashes if the new uri is NULL. Fixes: 2cec94bacce4a09c0e5ffa241b8d50fd4702dddc https://bugzilla.redhat.com/show_bug.cgi?id=1634500
2018-10-01 09:40:14 +02:00
if (uri)
host_and_port_from_uri (uri, &priv->host, &priv->port);
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
/* Set the interval. */
interval = nm_config_data_get_connectivity_interval (config_data);
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
interval = MIN (interval, (7 * 24 * 3600));
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
if (priv->interval != interval) {
priv->interval = interval;
changed = TRUE;
}
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: 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
enabled = FALSE;
#if WITH_CONCHECK
if ( priv->uri
connectivity: create a multi-handle for all requests This is dead ugly and works around what probably is a libcurl (7.59) bug: It shares the resolver cache among easy handles in a multi handle when it shouldn't: When we create two easy handles, one for IPv4 and one for IPv6 in a single mhandle: curl_easy_setopt (ehandle6, CURLOPT_RESOLVE, "fedoraproject.org:2605:bc80:3010:600:dead:beef:cafe:feda" "fedoraproject.org:2604:1580:fe00:0:dead:beef:cafe:fed1") curl_easy_setopt (ehandle4, CURLOPT_RESOLVE, "fedoraproject.org:8.43.85.67" "fedoraproject.org:152.19.134.198") curl_multi_add_handle (mhandle, ehandle6); curl_multi_add_handle (mhandle, ehandle4); Both end up connecting to the same (either v4 or v6) address. None of CURLOPT_FORBID_REUSE(3), CURLOPT_FRESH_CONNECT(3), CURLOPT_DNS_USE_GLOBAL_CACHE(3) and CURLOPT_DNS_CACHE_TIMEOUT(3) make any difference. Nor does CURLOPT_DNS_LOCAL_IP[46].
2018-07-03 20:23:06 +02:00
&& priv->interval)
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
enabled = nm_config_data_get_connectivity_enabled (config_data);
#endif
config: add an API to disable connectivity check via internal config file. https://bugzilla.gnome.org/show_bug.cgi?id=785117
2017-08-09 15:19:54 +08:00
if (priv->enabled != enabled) {
priv->enabled = enabled;
changed = TRUE;
}
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
/* Set the response. */
response = nm_config_data_get_connectivity_response (config_data);
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
if (!nm_streq0 (response, priv->response)) {
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
/* a response %NULL means, NM_CONFIG_DEFAULT_CONNECTIVITY_RESPONSE. Any other response
* (including "") is accepted. */
g_free (priv->response);
priv->response = g_strdup (response);
changed = TRUE;
}
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
if (changed)
g_signal_emit (self, signals[CONFIG_CHANGED], 0);
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
}
static void
config_changed_cb (NMConfig *config,
NMConfigData *config_data,
NMConfigChangeFlags changes,
NMConfigData *old_data,
NMConnectivity *self)
{
update_config (self, config_data);
}
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
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
static void
nm_connectivity_init (NMConnectivity *self)
{
NMConnectivityPrivate *priv = NM_CONNECTIVITY_GET_PRIVATE (self);
connectivity: improve curl error messages
2018-07-03 14:09:01 +02:00
#if WITH_CONCHECK
CURLcode ret;
#endif
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
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
c_list_init (&priv->handles_lst_head);
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
c_list_init (&priv->completed_handles_lst_head);
connectivity: switch connectivity checking to libcurl [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
2016-04-04 18:23:13 +02:00
connectivity: fix scheduling periodic connectivity checks commit a955639 (connectivity: don't do periodic checks on interval=0) broke scheduling connectivity checks. That is because the timer is on only scheduled if nm_connectivity_check_enabled(), which in turn only returns TRUE if curl_mhandle is set. However, nm_connectivity_init() would only initialize curl_mhandle after update_config(), missing to schedule the periodic task. https://mail.gnome.org/archives/networkmanager-list/2017-May/msg00076.html Fixes: a95563996f07641e9877eb1760cac24415b65070
2017-06-02 19:11:11 +02:00
priv->config = g_object_ref (nm_config_get ());
g_signal_connect (G_OBJECT (priv->config),
NM_CONFIG_SIGNAL_CONFIG_CHANGED,
G_CALLBACK (config_changed_cb),
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
#if WITH_CONCHECK
connectivity: improve curl error messages
2018-07-03 14:09:01 +02:00
ret = curl_global_init (CURL_GLOBAL_ALL);
connectivity: fix a wrong comparision Thanks clang 7. Fixes: cbfe6aa97310f0cc2d9031c5c5858be4741028c8
2018-09-24 15:52:07 +02:00
if (ret != CURLE_OK) {
connectivity: improve curl error messages
2018-07-03 14:09:01 +02:00
_LOGE ("unable to init cURL, connectivity check will not work: (%d) %s",
ret, curl_easy_strerror (ret));
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
}
#endif
update_config (self, nm_config_get_data (priv->config));
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
}
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
static void
core: connectivity check cleanups; check response headers too Clean up some memleaks and fix some possible lifecycle issues for strings. Also add a short-circuit check using the HTTP headers.
2011-12-05 14:48:47 -06:00
dispose (GObject *object)
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: clean up and simplify connectivity check We can just use property notifications instead of having a separate connected signal. Also clean up some formatting and make some private variable names shorter.
2011-12-13 17:35:36 -06:00
NMConnectivity *self = NM_CONNECTIVITY (object);
NMConnectivityPrivate *priv = NM_CONNECTIVITY_GET_PRIVATE (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
NMConnectivityCheckHandle *cb_data;
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
nm_assert (c_list_is_empty (&priv->completed_handles_lst_head));
while ((cb_data = c_list_first_entry (&priv->handles_lst_head,
NMConnectivityCheckHandle,
handles_lst)))
cb_data_complete (cb_data, NM_CONNECTIVITY_DISPOSING, "shutting down");
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: make NMConnectivity:dispose() reentrant
2014-07-09 22:22:48 +02:00
g_clear_pointer (&priv->uri, g_free);
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
g_clear_pointer (&priv->host, g_free);
g_clear_pointer (&priv->port, g_free);
connectivity: make NMConnectivity:dispose() reentrant
2014-07-09 22:22:48 +02:00
g_clear_pointer (&priv->response, g_free);
core: build NMConnectivity unconditionally, possibly as a no-op Build and use NMConnectivity regardless of build options; if you build without libsoup, NMConnectivity will just always report that you have full connectivity (like it does when you build with libsoup but don't enable connectivity checking).
2013-07-29 16:36:00 -04:00
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
#if WITH_CONCHECK
curl_global_cleanup ();
#endif
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
if (priv->config) {
g_signal_handlers_disconnect_by_func (priv->config, config_changed_cb, self);
g_clear_object (&priv->config);
}
connectivity: fix calling parent dispose()
2016-02-01 13:15:40 +01:00
G_OBJECT_CLASS (nm_connectivity_parent_class)->dispose (object);
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
}
static void
nm_connectivity_class_init (NMConnectivityClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
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
signals[CONFIG_CHANGED] =
g_signal_new (NM_CONNECTIVITY_CONFIG_CHANGED,
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
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 0);
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
object_class->dispose = dispose;
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
}
Reference in a new issue Copy permalink