summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* device: penalize default route metrics for connectivity failureslr/device-connLubomir Rintel2017-03-282-30/+65
| | | | | | This makes it possible to retain Internet connectivity when multiple devices have a default route, but one with the link type of a higher priority can not reach the Internet.
* core: make connectivity checking per-deviceLubomir Rintel2017-03-287-421/+399
| | | | | | | | | | | | | 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.
* tests/general: allow error margin on comparing floatsLubomir Rintel2017-03-282-2/+2
| | | | Fixes test on Fedora/i686.
* tests/lldp: skip test if there's no Tun deviceLubomir Rintel2017-03-281-2/+12
|
* Remove assertion for empty DHCP optionsAlfonso Sánchez-Beato2017-03-281-1/+0
| | | | | | | | | | It turns out that some routers return responses to DHCP6 Information-request messages that do not contain any of the options that we insert in the "options" table. When that happened and the info-only flag for DHCP6 was set, the assertion was triggered and NetworkManager crashed. We remove the assertion as having empty options is a possibility and is harmless anyway. This happened while using the internal dhclient.
* manager: sort slaves to be autoconnected by device nameBeniamino Galvani2017-03-271-0/+20
| | | | | Autoconnect slaves based on device name order instead of activation timestamp.
* manager: rework find_slaves() to return the matching deviceBeniamino Galvani2017-03-271-37/+61
| | | | | | | Perform the lookup for a matching device earlier, so that in autoconnect_slaves() we already know which device a connection is being activated on. This will be needed to sort the returned connections by interface name.
* manager: change nm_manager_get_best_device_for_connection() signatureBeniamino Galvani2017-03-271-3/+8
| | | | | Add a @unavailable_devices argument that specifies an hash table of devices to be excluded from the search.
* platform: sort links by name instead of ifindexBeniamino Galvani2017-03-271-3/+11
| | | | | | | | | | | | | | | | | We should try to guarantee a stable activation order of connections across reboots; this is required, for example, for bonds because they get assigned the MAC address of the first device enslaved, and thus changing the activation order of slaves means also changing the MAC address of the bond. Since we activate connections in the order links are discovered, having a stable sorting of links returned by platform is enough. The ifindex of interfaces can change between reboots as it depends on the order in which kernel discover interfaces. Provided that the system uses a mechanism to enforce persistent interface naming (as udev rules or systemd-udevd predictable names), and that NM starts after all interfaces have been announced by udev, using the interface name instead of ifindex will guarantee a consistent order.
* manager: check that slaves connection have a compatible deviceBeniamino Galvani2017-03-271-1/+16
| | | | | | | | When slave connections are autoactivated as dependency to master we don't check if a compatible device is available before trying to activate them, leading to the following failed assertion: nm_act_request_new: assertion 'NM_IS_DEVICE (device)' failed
* policy: add some verbose logging for tracking hostname managementFrancesco Giudici2017-03-241-18/+24
|
* policy: allow reset of dhcp hostname in "dhcp" hostname-mode config.Francesco Giudici2017-03-241-1/+18
| | | | | | | | | | | | | When dhcp hostname-mode is selected, NetworkManager will just update the hostname with information available from DHCP (if any). So, when a connection providing a DHCP host-name option is brought up we update the transient hostname. When it is later teared down, this will trigger NetworkManager to update the hostname: this time no DHCP host-name option will be found and so the hostname will not be changed, keeping the obsoleted one from the disappeared DHCP option. In order to fix this we have to keep track if the last hostname set was retrieved from the DHCP host-name option: in this case NetworkManager will be able to reset it by applying back the previous hostname.
* policy: add support to configurable hostname modeFrancesco Giudici2017-03-243-0/+38
|
* nm-config: fix comment typoFrancesco Giudici2017-03-241-1/+1
|
* policy: skip dns and route updates on ip6 config change signal if the device ↵Francesco Giudici2017-03-241-5/+7
| | | | | | is not active This pairs with commit 30a1e17cc032676cdfb04e2abcfab9db0d0cf085.
* policy: detect if the hostname was changed outside NetworkManagerFrancesco Giudici2017-03-241-15/+74
| | | | | | | When updating the hostname we can now detect if someone else changed the hostname: if so, search for hostname candidates in the dhcp configuration but avoid to fallback to the hostname saved when NM started or querying dns for a reverse lookup of the current IP.
* policy: remove redundant check in _set_hostnameFrancesco Giudici2017-03-241-13/+4
| | | | | This will allow also to remove the hostname_changed var from NMPolicyPrivate struct.
* policy: try to retrieve hostname from dbus firstFrancesco Giudici2017-03-243-18/+78
| | | | | | | As we try to set the hostname through dbus, we should also try to retrieve current hostname value from dbus first: otherwise we may end retrieving the "old" hostname via gethostname while the dbus hostnamed updated is pending.
* device: deal with non-existing IP settings in get_ip_config_may_fail()Beniamino Galvani2017-03-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the IP setting does not exist, consider the IP method as may-fail=yes. This simplifies the decision path in check_ip_state(), where the value of may-fail is used to decide whether we must wait for the IP method to complete. If there is no IP setting (i.e. the device is a slave), we don't have to wait for it to be applied. Fixes the following: nm_setting_ip_config_get_may_fail: assertion 'NM_IS_SETTING_IP_CONFIG (setting)' failed Process terminating with default action of signal 5 (SIGTRAP): dumping core at 0x6C95643: g_logv (gmessages.c:1086) by 0x6C957BE: g_log (gmessages.c:1119) by 0x193CB3: nm_setting_ip_config_get_may_fail (nm-setting-ip-config.c:2336) by 0x2431D0: check_ip_state (nm-device.c:4643) by 0x24770B: nm_device_activate_stage3_ip6_start (nm-device.c:7594) by 0x247EC7: nm_device_master_enslave_slave (nm-device.c:1769) by 0x8659DCB: ffi_call_unix64 (unix64.S:76) by 0x86596F4: ffi_call (ffi64.c:522) by 0x6801147: g_cclosure_marshal_generic (gclosure.c:1487) by 0x6800907: g_closure_invoke (gclosure.c:801) by 0x6812A1C: signal_emit_unlocked_R (gsignal.c:3627) by 0x681AAB0: g_signal_emit_valist (gsignal.c:3383) by 0x681AD9E: g_signal_emit (gsignal.c:3439) by 0x241F04: _set_state_full (nm-device.c:12272) by 0x248E86: activate_stage3_ip_config_start (nm-device.c:7626) by 0x227D83: activation_source_handle_cb (nm-device.c:4204) by 0x227E3D: activation_source_handle_cb4 (nm-device.c:4141) by 0x6C8ED79: g_main_dispatch (gmain.c:3152) by 0x6C8ED79: g_main_context_dispatch (gmain.c:3767) by 0x6C8F0B7: g_main_context_iterate.isra.24 (gmain.c:3838) by 0x6C8F389: g_main_loop_run (gmain.c:4032) by 0x139A80: main (main.c:425)
* iface-helper: log the device contextlr/log-hints-1Lubomir Rintel2017-03-241-1/+1
|
* keyfile: log the connection contextLubomir Rintel2017-03-241-1/+3
|
* vpn/vpn-connection: log the connection contextLubomir Rintel2017-03-241-6/+6
|
* settings-connection: log the connection contextLubomir Rintel2017-03-241-3/+2
|
* active-connection: log the connection contextLubomir Rintel2017-03-241-1/+5
|
* wwan/modem-broadband: log the connection contextLubomir Rintel2017-03-241-1/+4
|
* supplicant: log the device contextLubomir Rintel2017-03-241-7/+3
|
* ndisc: log the device contextLubomir Rintel2017-03-241-7/+5
|
* dhcp: log the device contextLubomir Rintel2017-03-241-2/+2
|
* devices/lldp: log the device contextLubomir Rintel2017-03-241-1/+3
|
* devices/arping-manager: log the device contextLubomir Rintel2017-03-243-6/+7
|
* 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
|
View Lorry Controller Status