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
(cherry picked from commit 0234172923)
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
(cherry picked from commit 3cada7722d)
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.
(cherry picked from commit b139552255)
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
(cherry picked from commit 3ad89223d0)
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;
^
(cherry picked from commit f66de1dd0f)
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.
(cherry picked from commit 3fe144f934)
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
(cherry picked from commit 166988264f)
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.
Currently, we determine NMD_CONNECTION_PROPS_EXTERNAL based
on the settings connection. That is not optimal, because whether
a connection is assumed or externally managed, should be really a
property of the active-connection. So, in the this will change soon
and we would need yet another argument to nm_dispatcher_call().
Instead, drop the settings-connection and applied-connection
arguments and fetch them from the device as needed (but allow
to pass a specific act-request argument to explicitly state
which active connection to use).
Also, rename nm_dispatcher_call() to nm_dispatcher_call_device(),
it this is not a generic dispatcher call, but it is particularly
related to device events. Likewise, rename nm_dispatcher_call_sync()
to nm_dispatcher_call_device_sync().
Scenario:
Have a connection with DHCPv4 and a default-route. When externally
removing the default route (`ip route delete 0.0.0.0/0`) and issuing
`nmcli device reapply $IF`, the default route was not restored.
That was because when externally removing the default route,
we would remove the gateway from priv->con_ip4_config (see
update_ip4_config()). Later, when reapplying the connection,
the IP method doesn't actually change. So we would not restart
DHCP and thus there is no gateway around to add the default route.
The default route would only be restored after receiving a DHCP lease
in the far future.
Fix that, by always restarting the IP method.
Based on this flag, we decide that:
- if we are not gonna commit the first time and the
connection is configured with never-default, we
would not remove a default route added externally.
During a reapply, we however want to get rid of an externally
configured default route.
Commit 4a6fd0e83e ("device: honor the connection.autoconnect-retries
for 802.1X") added a reset of the autoconnect retries when the device
changes state, because the retry logic for 802.1x is implemented in
NMDeviceEthernet. For other connections, we should not reset the
retries as NMPolicy handles them.
Fixes: 4a6fd0e83e
Instead of throwing an assertion, fail DHCPv6 when a IPv6 link-local
address is not configured on the device. There are different reasons
why the assertion may fail: for example the address was removed
externally; or the device is gone (and thus the platform already
received the notification of addresses removal) but the device is still
connecting because its disposal happens in an idle callback.
None of these deserves an assertion, which should only be for
programming errors.
https://bugzilla.redhat.com/show_bug.cgi?id=1432251
Udev may be slow at startup and it may take a while until the
device is visible in udev. Before that, there are no pending
actions yet because the device is still in unmanaged state.
Hack nm_device_has_pending_action() to indicate a pending action
when the platform link is not yet initialized.
We don't bother using nm_device_add_pending_action() to schedule
a proper pending-action. It is simpler this way, also we precisely
log about the state of NM_UNMANAGED_PLATFORM_INIT flag. The pending
actions are implemented in their way mostly for logging purpose to
understand what blocks a device. For NM_UNMANAGED_PLATFORM_INIT we
have sufficient logging so no need for the overhead and effort.
https://bugzilla.gnome.org/show_bug.cgi?id=779920
In order to support a reapply of proxy configuration, remember the PAC
URL received through DHCP and merge it again with configuration from
proxy setting on reapply.
In practice, this should only matter when there are multiple
header files with the same name. That is something we try
to avoid already, by giving headers a distinct name.
When building NetworkManager itself, we clearly want to use
double-quotes for including our own headers.
But we also want to do that in our public headers. For example:
./a.c
#include <stdio.h>
#include <nm-1.h>
void main() {
printf ("INCLUDED %s/nm-2.h\n", SYMB);
}
./1/nm-1.h
#include <nm-2.h>
./1/nm-2.h
#define SYMB "1"
./2/nm-2.h
#define SYMB "2"
$ cc -I./2 -I./1 ./a.c
$ ./a.out
INCLUDED 2/nm-2.h
Exceptions to this are
- headers in "shared/nm-utils" that include <NetworkManager.h>. These
headers are copied into projects and hence used like headers owned by
those projects.
- examples/C
