Before, setting a device to unmanaged causes it to go down and clear
the interface state.
It may be useful to instruct NetworkManager not to touch the device
anymore but leave the current state up. Changing behavior for
nmcli device set "$DEV" managed no
To get the previous behavior, one has to first disconnect the interface
via
nmcli device disconnect "$DEV"
nmcli device set "$DEV" managed no
Note that non-permanent addresses like from DHCP will eventually time
out because NetworkManager stops the DHCP client. When instructing
NetworkManager to let go of the device, you have to take it over in
any way you see fit.
https://bugzilla.redhat.com/show_bug.cgi?id=1371433
Reduce the use of NM_PLATFORM_GET / nm_platform_get() to get
the platform singleton instance.
For one, this is a step towards supporting namespaces, where we need
to use different NMNetns/NMPlatform instances depending on in which
namespace the device lives.
Also, we should reduce our use of singletons. They are difficult to
coordinate on shutdown. Instead there should be a clear order of
dependencies, expressed by owning a reference to those singelton
instances. We already own a reference to the platform singelton,
so use it and avoid NM_PLATFORM_GET.
This also ensures that we own a reference to the
NMPlatform, NMRouteManager and NMDefaultRouteManager
instances. See bug rh#1440089 where we might access
the singleton getter after destroing the singleton
instance of NMRouteManager. This is prevented by
keeping a reference to those instances -- indirectly
via the netns instance.
Later, we may add support for multiple namespaces. Then it might
make sense to swap the NMNetns instance of a device when moving
the device between namespaces.
Also, drop the use of singelton instances.
https://bugzilla.redhat.com/show_bug.cgi?id=1440089
The address change involves setting the link down which causes the supplicant
interface to change state and in turn another scan attempt. This could lead to
a loop in case of broken drivers that are not able to change the MAC address
iff the MAC address is attempted at each scan request.
https://bugzilla.redhat.com/show_bug.cgi?id=1382741
IEEE_80211_IE_VHT_CAP has zero hits searching the internet.
WLAN_EID_VHT_CAPABILITY is how the same define is called by
kernel's "include/linux/ieee80211.h".
Use the same name as kernel.
Also, collect the maximum of @max_rate.
Currently, 'nmcli dev wifi list' does not show the user any rates above
54Mbps. Now, we can check the IEs passed to NM from the wpa_supplicant,
pull the mcs rate and channel width information, and determine a maximum
possible data rate for 11n and 11ac APs.
https://bugzilla.gnome.org/show_bug.cgi?id=779771
src/devices/nm-device-bond.c: In function 'check_changed_options':
src/devices/nm-device-bond.c:529:4: error: 'name' may be used uninitialized in this function [-Werror=maybe-uninitialized]
g_set_error (error,
^
src/devices/nm-device-bond.c:505:14: note: 'name' was declared here
const char *name, *value_a, *value_b;
^
src/devices/nm-device-bond.c:528:8: error: 'value_a' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!nm_streq0 (value_a, value_b)) {
^
src/devices/nm-device-bond.c:505:21: note: 'value_a' was declared here
const char *name, *value_a, *value_b;
^
Don't try to remove the configuration if we haven't added it in the
first place, for example when the connection gets deactivated before
it completes or for slave connections without IP configuration.
Fixes: 3ad89223d0
If a VPN provides a proxy, we want to restrict the usage of that proxy
to URLs in the VPN domain. For all other connections, the proxy should
be used for all domains.
Fix some issues in nm-pacrunner-manager.c:
- when adding a configuration through nm_pacrunner_manager_send(), we
kept an association between the interface name and the pacrunner
configuration object path, so that the configuration for that
interface could be removed later. Unfortunately not all
configurations have an interface associated, so we need a more
generic way to identify configurations. Introduce a new @tag
argument that serves as key to match configurations
- the interface name of the last pushed configuration was stored in
the manager private config and reused later; this could cause
issues when there are multiple outstanding D-Bus calls. The
interface is not needed anymore after the previous point.
- remove() didn't actually remove the configuration from the list
We now update the default route metric based on the result of the
connectivity check. When we update the metric and there is no other
changes to the IP configuration, NMPolicy is not notified about it and
can't update the best device until an actual change in IP config
happens. This results in a wrong best device set in NMPolicy.
NMDevice has NM_DEVICE_IP[4,6]_CONFIG_CHANGED signals that are used
exclusively by NMPolicy to detect when there is a change in
configuration that requires an update of global DNS and routing
information. Emit those signals also when the default route changes.
Commit 029a0a21ea ("device: split out cloned MAC decision from
nm_device_hw_addr_set_cloned()") accidentally removed the assignment
of the new device @hw_addr_type, which then was left to
HW_ADDR_TYPE_UNSET. As a consequence, we never restored the initial
MAC address when the connection was deactivated. Fix this.
Fixes: 029a0a21ea
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.
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.
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)
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.
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.
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.
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.
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.
The concept of assumed-connection will change. Currently we mark
connections that are generated and assumed as "nm-generated-assumed".
That has several consequences, one of them being that such a settings
connection gets deleted when the device disconnects.
That is, such a settings connection lingers around as long as it's active,
but once it deactivates it gets automatically deleted. As such, it's
a more volatile concept of an in-memory connection.
The concept of such automatically cleaned up connections is useful beyond
generated-assumed. See the related bug rh#1401515.
