It's not sufficient to make nm-core-enum-types.[ch] depend on the
dirstamp, because they also depend on their own stamps that are to be
placed in libnm-core.
$ make libnm-core/nm-core-enum-types.h.stamp
GEN libnm-core/nm-core-enum-types.h
/bin/sh: libnm-core/nm-core-enum-types.h.tmp: No such file or directory
../../Makefile.glib:107: recipe for target 'libnm-core/nm-core-enum-types.h.stamp' failed
make: *** [libnm-core/nm-core-enum-types.h.stamp] Error 1
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.
No need to create a separate NMUdevClient instance for all devices.
Instead, have one "struct udev" instance in NMClient and pass
it down during object construction.
GUdevClient always creates a monitor instance, even if there are no subsystems
or handlers defined. Hence the first iteration of NMUdevClient did that as
well.
I think that can be avoided however. We only need a monitor when there is
a event handler subscribed. Contrary to GUdevClient, we know that from the
very beginning.
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.
state_changed_proxy() updates the value of @state and must also emit
the notify signal for it.
Without this, when the PropertiesChanged signal carrying the change of
'state' arrives after StateChanged, we notice that the value of @state
doesn't change and don't emit the notify, causing a loss of the state
change event.
Fixes: 40ffb962behttps://bugzilla.redhat.com/show_bug.cgi?id=1433883
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
NMVpnConnectionStateReason is no longer used and replaced by
NMActiveConnectionStateReason. However, the old enums should
stay in place as they were:
Otherwise:
#define NMVpnConnectionStateReason NMActiveConnectionStateReason
causes compiler warnings:
NMVpnConnectionStateReason x;
x = NM_VPN_CONNECTION_STATE_REASON_UNKNOWN; // -Wenum-conversion
if (x == NM_VPN_CONNECTION_STATE_REASON_NO_SECRETS) { } // -Wenum-compare
Similarly, a user who didn't upgrade shall continue to get the
old GType for NM_TYPE_VPN_CONNECTION_STATE_REASON.
In practice, old users will have no issues using the old enum
the places where it worked before.
The only use of the deprecated enum is in vpn_state_changed()
signal slot of NMVpnConnection. This makes the signal slot
itself deprecated. However, NMVpnConnection is an NMObject and commonly
created within libnm itself, not by the user. It is very unlikely that
a user of libnm subclassed NMVpnConnection and makes use of the
vpn_state_changed() signal slot. So, deprecate it without replacement.
Fixes: a91369f80d
