summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
* | devices: log the device contextLubomir Rintel2017-03-241-1/+3
| |
* | logging: log device and connection along with the messageLubomir Rintel2017-03-2443-75/+118
| |
* | logging: respect choice of journal/syslog even with --debugLubomir Rintel2017-03-244-16/+18
| | | | | | | | | | | | Previously, the daemon would just use syslog with LOG_PERROR when run with --debug option, even when actually configured to log into the journal. Let's respect the configuration, but preserve the logging to stderr.
* | core/trivial: rename nm_utils_10pow() to nm_utils_exp10()Thomas Haller2017-03-244-33/+33
| | | | | | | | | | | | nm_utils_exp10() is a better name, because it reminds of the function exp10() from <math.h> which has a similar purpose (but whose argument is double, not gint16).
* | build: don't link against libm.soThomas Haller2017-03-232-5/+2
| | | | | | | | | | | | | | | | | | There are very few places where we actually use floating point or #include <math.h>. Drop that library, although we very likely still get it as indirect dependency (e.g. on my system it is still dragged in by libsystemd.so, libudev.so and libnl-3.so).
* | core: add nm_utils_10pow() utilsThomas Haller2017-03-233-0/+85
| |
* | ifcfg-rh: fix coding styleBeniamino Galvani2017-03-233-35/+36
| |
* | dns: avoid cleaning resolv.conf on exit if not neededFrancesco Giudici2017-03-231-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | When rc-manager=file other services may overwrite resolv.conf at any time. We don't support merging configurations in resolv.conf but we can be more tolerant avoiding updating resolv.conf when not strictly needed. In this case, if the last write of resolv.conf had no nameservers (nor options), reset the "dns_touched" flag in order to avoid resetting resolv.conf when quitting (so, potentially overwriting some other service configuration there). https://bugzilla.redhat.com/show_bug.cgi?id=1426748
* | nm-manager: Use g_dbus_message_new_method_error_literal()Iain Lane2017-03-231-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GLib 2.52 added a G_GNUC_PRINTF attribute to g_dbus_message_new_method_error(). This triggered warning in NetworkManager when built with -Wformat, which is an error when built with -Werror=format-security. It seems that gcc isn't smart enough to see that (foo = "bar") should be treated as a literal. Fortunately there is a g_dbus_message_new_method_error_literal() function which does not take printf-style arguments, and we don't need them, so we can use that. This patch was originally by Rico Tzschichholz <ricotz@ubuntu.com>, and was submitted to Launchpad at https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1650972 https://bugzilla.gnome.org/show_bug.cgi?id=780444
* | connectivity: remove verbose trace loggingThomas Haller2017-03-231-14/+1
| |
* | platform: remove debug logging messages from "nmp-object.c"Thomas Haller2017-03-231-10/+0
| |
* | connectivity: fix clearing timer-id in curl_timeout_cb()Thomas Haller2017-03-221-0/+2
| | | | | | | | Fixes: 7307dea9c4da6cdc53e4c23c4ce07cf51bd0c4b7
* | connectivity: fix the connectivity check timeoutLubomir Rintel2017-03-221-3/+20
| | | | | | | | | | | | 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.
* | connectivity: conclude the check as soon as we see enough bytesLubomir Rintel2017-03-221-17/+23
| | | | | | | | No need to read the full response into memory.
* | connectivity: conclude the check as soon as we see the magic headerLubomir Rintel2017-03-221-8/+3
| | | | | | | | No need to read the rest of the reponse.
* | connectivity: split out the finish of the connectivity checkingLubomir Rintel2017-03-221-46/+61
| | | | | | | | | | | | | | | | 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.
* | connectivity: cosmetic fixesLubomir Rintel2017-03-221-2/+3
| |
* | udev: drop libgudev in favor of libudevThomas Haller2017-03-2212-261/+345
| | | | | | | | | | | | libgudev is just a wrapper around libudev. We can use libudev directly and drop the dependency for libgudev.
* | device: apply a loose IPv4 rp_filter when it would interfere with multihominglr/rp-filterLubomir Rintel2017-03-221-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The IPv4 Strict Reverse Path Forwarding filter (RFC 3704) drops legitimate traffic when the same route is present on multiple interfaces, which is a pretty common scenario for IPv4 hosts. In particular, if the traffic is routable via multiple interfaces it drops traffic incoming via the device that has lower metric on the route to the originating network. Among other things, this disrupts existing connection when the user connected to the Internet via Wi-Fi activates a Wired Ethernet connection that also has a default route. Also, the Strict filter (and Reverse Path filters in general) provide practically no value to hosts that have a default route. The solution this patch uses is to detect scenarios where Strict filter is known to interfere and switch to a saner RP filter on the affected links. Routes to the same network on multiple interfaces is a good indication the RP filter would drop the legitimate traffice from the link with a lower metric. This includes the default routes. In such cases, we switch to the Loose Reverse Path Forwarding. This addresses the problems the multihomed hosts face, at the cost of disabling filtering altogether when a default route is present. A Feasible Path Reverse Path Forwarding would address the main problems with the Strict filter, but it's not implemented by the Linux kernel.
* | device: add convenience routines for IPv4 sysctlsLubomir Rintel2017-03-221-0/+32
| |
* | route-manager: emit a signal when IPv4 routes changeLubomir Rintel2017-03-222-0/+18
| | | | | | | | The devices will use this to reconsider their RP filtering decisions.
* | route-manager: add routine to query route shadowing for a linkLubomir Rintel2017-03-222-0/+28
| | | | | | | | | | If a route is shadowed by another route to the same network it's a good indication we're multihoming and want to disable the Strict RP filtering.
* | ppp: only request IPV6CP when IPv6 is enabled in the connectionDan Williams2017-03-221-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | NM always asks pppd to run IPV6CP which will complete if the modem supports IPv6. If the user doesn't want IPv6 then NM just ignores the result. But if the host has disabled IPv6, then pppd will fail to complete the connection because pppd tries to assign the Link-Local address to the pppX interface, and if IPv6 is disabled that fails and terminates the PPP session. So only request IPV6CP when the user wants IPv6 on the connection; if they have disabled IPv6 on their host then they can simply set ipv6.method=ignore. https://mail.gnome.org/archives/networkmanager-list/2017-March/msg00047.html
* | connectivity: switch connectivity checking to libcurllr/fg/libcurl_bgo752642Francesco Giudici2017-03-221-112/+296
| | | | | | | | | | | | | | [lkundrak@v3.sk: removed libsoup altogether, implemented TODOs and fixed the poll condition handling] Co-authored-by: Lubomir Rintel <lkundrak@v3.sk>
* | dns-manager: turn DOMAIN_IS_VALID into a functionLubomir Rintel2017-03-221-15/+24
| |
* | dns-manager: use libpsl directlyLubomir Rintel2017-03-221-11/+4
| | | | | | | | | | ...instead of via libsoup. This makes it possible to do gTLD suffix checking even if we're building without libsoup support.
* | core,libnm-core: use same route attribute names of iproute2Beniamino Galvani2017-03-227-21/+21
| | | | | | | | | | | | | | Users are probably more familiar with iproute2 route option names than kernel ones. Fixes: 54e58eb96bbfcd26d31ddba2e98ff2c59335a02a
* | wifi-utils: nl80211: use logging macrosBeniamino Galvani2017-03-211-25/+35
| |
* | wifi-utils: wext: use logging macrosBeniamino Galvani2017-03-211-80/+89
| |
* | wifi-utils: fix use of errnoBeniamino Galvani2017-03-211-1/+3
| | | | | | | | It can be overwritten when other arguments are evaluated.
* | wifi-utils: don't cache interface nameBeniamino Galvani2017-03-218-95/+143
| | | | | | | | | | | | | | For nl80211, we don't care about the interface name and only use it when formatting error messages. For wext, an up-to-date interface name should be obtained every time to minimize the chance of race conditions when the interface is renamed.
* | manager: ensure proper disposal of unrealized devicesBeniamino Galvani2017-03-211-0/+5
| | | | | | | | | | | | | | | | When remove_device() is called on an already unrealized device, we should release it from master if necessary and clear its IP configurations to avoid leaks. https://bugzilla.redhat.com/show_bug.cgi?id=1433303
* | device: add spec "driver:" to match devicesThomas Haller2017-03-174-2/+74
| | | | | | | | | | | | | | | | Changing the MAC address of devices is known to fail with certain drivers. Add a device-spec to allow disabling it for for such devices. Related: https://bugzilla.gnome.org/show_bug.cgi?id=777523
* | all: fix typos in documentation and commentsYuri Chornoivan2017-03-172-2/+2
| | | | | | | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=780199 [thaller@redhat.com: reworded commit message]
* | vpn-connection: use NMActiveConnectionStateReasonlr/active-connection-state-changedLubomir Rintel2017-03-174-43/+43
| |
* | vpn-connection: drop reason_to_stringLubomir Rintel2017-03-171-19/+0
| | | | | | | | | | | | It's utterly useless: the textual version of the reason if logged only if the plugin fails; but the plugin failure already logs the plugin state change reason which is directly translated to the connection one.
* | libnm/active-connection: track reason for state changesLubomir Rintel2017-03-171-1/+1
| | | | | | | | | | | | | | | | | | Note that the reason tracking starts as soon as the object exists (which is immediately after GDBusObject is created), not when the asynchronous NMObject initialization finishes. That is so that we the reason changes in between are not lost. The vpn-connection should probably be doing the same.
* | active-connection: emit a StateChanged signal on state changesLubomir Rintel2017-03-176-11/+40
| | | | | | | | | | | | | | | | It includes a reason code that makes it possible for the clients to be more reasonable about error messages. The reason code is essentially copied from the VPN, plus three more reasons that were useful for non-VPN connections.
* | device: cast enum types for variadic g_signal_emit() functionThomas Haller2017-03-171-1/+1
| |
* | device: track system interface state in NMDeviceThomas Haller2017-03-167-91/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When deciding whether to touch a device we sometimes look at whether the active connection is external/assumed. In many cases however, there is no active connection around (e.g. while moving the device from state unmanaged to disconnected before assuming). So in most cases we instead look at the device-state-reason to decide whether to touch the interface (see nm_device_state_reason_check()). Often it's desirable to have no state and passing data as function arguments. However, the state reason has to be passed along several hops (e.g. a queued state change). Or a change to a master/slave can affect the slave/master, where we pass on the state reason. Or an intermediate event might invalidate a previous state reason. Passing the state whether to touch a device or not as a state-reason is cumbersome and limited. Instead, the device should be aware of whats going on. Add a sys-iface-state with: - SYS_IFACE_STATE_EXTERNAL: meaning, NM should not touch it - SYS_IFACE_STATE_ASSUME: meaning, NM is gracefully taking over - SYS_IFACE_STATE_MANAGED: meaning, the device is managed by NM - SYS_IFACE_STATE_REMOVED: the device no longer exists This replaces most checks of nm_device_state_reason_check() and nm_active_connection_get_activation_type() by instead looking at the sys-iface-state of the device. This patch probably has still issues, but the previous behavior was not very clear either. We will need to identify those issues in future tests and tweak the behavior. At least, now there is one flag that describes how to behave.
* | manager: always cleanup volatile settings-connection on active-connection ↵Thomas Haller2017-03-161-2/+1
| | | | | | | | | | | | | | removal This is not only relevant if the active connection is assumed/external.
* | manager: simplify searching assumed connectionThomas Haller2017-03-164-39/+61
| | | | | | | | | | | | Now we only search for a candiate with matching UUID. No need to first lookup all activatable connections, just find the candidate by UUID and see if it is activatable.
* | manager: cleanup find_ac_for_connection() in "nm-manager.c"Thomas Haller2017-03-161-40/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - rename find_ac_for_connection() to active_connection_find_first_by_connection(). This function has the unexpected(?) behavior to either search by the @connection using pointer identity, or by looking up the UUID (depending on whether @connection is a NMSettingsConnection). - Split out a active_connection_find_first() part. The name "find-first" makes it clear that we walk the list until a matching active-connection is found. That's why I added the max_state argument. Otherwise, it would have to be called "find-first-non-disconnected". - drop nm_manager_get_connection_device(). It only had two callers. It also used the ambiguity of the @connection argument, but only one of the two callers cared about that. Meaning, _internal_activate_device() now explicitly does a lookup by the NMSettingsConnection.
* | manager: merge/inline assume_connection() in recheck_assume_connection()Thomas Haller2017-03-161-62/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is only one caller of assume_connection(). The tasks there are not clearly separate and it is clearer just to have one large recheck_assume_connection() function which proceeds step by step, instead of breaking it into separate parts and move them apart in the source code. The latter implies that -- unless we forward-declare assume_connection() -- the order of definition with assume_connection,recheck_assume_connection is contrary the flow of the code. Having a separate function in this case is not a simplification so merge it.
* | core: once activated an assumed connection make it NM_ACTIVATION_TYPE_MANAGEDThomas Haller2017-03-161-0/+10
| |
* | core: upgrade EXTERNAL activation type when user saves connectionThomas Haller2017-03-161-6/+45
| | | | | | | | | | | | An EXTERNAL activation type comes with a nm-generated, volatile, in-memory connection. When the user actively modifies that connection, we shall mark the active connection as fully managed.
* | core: only assume connections that were managed in a previous run of ↵Thomas Haller2017-03-161-30/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NetworkManager Before, we would have the concept of assumed connections, which is used for (1) externally configured device that NetworkManager should not touch and (2) connections that NetworkManager should gracefully take over after a restart (seamlessly, non-destructively). The behavior was unclear and mixed. It wasn't clear whether the device is in no-touch mode (1) or gracefully take-over (2). Previous commits already introduce separate activation types EXTERNAL (1) and ASSUME (2). Also, previously, we would for both (1) and (2) try to find a matching connection and use it. That doesn't make sense for either. In the external case (1), we should not pretend that an existing connection is active. Let's always create a new in-memory connection for these cases. Note that this means, external devices now will always generate a connection, instead of pretending an existing one is active. For the assume case (2), we shall not use nm_utils_match_connection() to guess which connection might be active. It can only the one that was active on a previous run of NetworkManager. So, use the information from the state file and try to activate it. If that fails, it is not an assume activation type. Note, that this means we now most of the time don't do ASSUME anymore. Most of the time we do EXTERNAL activation That is because the state information is only available after restart of NetworkManager.
* | core: track external activations types in the active-connectionThomas Haller2017-03-166-40/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need a distinction between external activations and assuming connections. The former shall have the meaning of devices that are *not* managed by NetworkManager, the latter are configurations that are gracefully taken over after restart (but fully managed). Express that in the activation-type of the active connection. Also, no longer use the settings NM_SETTINGS_CONNECTION_FLAGS_VOLATILE flag to determine whether an assumed connection is "external". These concepts are entirely orthogonal (although in pratice, external activations are in-memory and flagged as volatile, but the inverse is not necessarily true). Also change match_connection_filter() to consider all connections. Later, we only call nm_utils_match_connection() for the connection we want to assume -- which will be a regular settings connection, not a generated one.
* | core/trivial: rename activation-type related checks for device and ↵Thomas Haller2017-03-167-40/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | active-connection nm_device_uses_assumed_connection() basically called nm_active_connection_get_assumed() on the device. Rename those functions to be closer to the activation-type flags. The concepts of "assume", "external", and "assume_or_external" will make sense with the following commits.
* | active-connection: use activation-type for active connection instead of ↵Thomas Haller2017-03-163-22/+3
| | | | | | | | assumed flag
View Lorry Controller Status