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.
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.
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.
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)
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.
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).
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).
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
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/1650972https://bugzilla.gnome.org/show_bug.cgi?id=780444
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.
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.
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.
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
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.
