Don't just directly switch to DISCONNECTED state. If we are ACTIVATING
or ACTIVATED, first transition to DISCONNECTING state.
(cherry picked from commit 6d623825f6)
We already avoid committing the IP configuration for external devices
(see commit 60334a2893). However, we still start DHCP/IPv6-autoconf
and, especially, we change sysctl values of the device.
To be sure that no action is taken on the device, return early from
the IP configuration phase, as in the method=disabled/ignore case.
https://bugzilla.redhat.com/show_bug.cgi?id=1530288
(cherry picked from commit 22f32a16f5)
Add a new device state reason code for unsupported IP method. It is
returned, for example, when users select manual IP configuration for
WWAN connections:
# nmcli connection mod Gsm ipv4.method manual ipv4.address 1.2.3.4/32
# nmcli connection up Gsm
Error: Connection activation failed: The selected IP method is not
supported
compared to the old:
Error: Connection activation failed: IP configuration could not be
reserved (no available address, timeout, etc.)
Note that we could instead fail the connection validation if the
method is not supported by the connection type, but adding such
limitation now could make existing connections invalid.
https://bugzilla.redhat.com/show_bug.cgi?id=1459529
(cherry picked from commit aa820e9386)
In the past we had NMDefaultRouteManager which would coordinate adding
the default-route with identical metrics. That especially happened, when
activating two devices of the same type, without explicitly specifying
ipv4.route-metric. For example, with ethernet devices, the routes on
both interfaces would get a metric of 100.
Coordinating routes was especially necessary, because we added
routes with NLM_F_EXCL flag, akin to `ip route replace`. We not
only had to avoid that activating two devices in NetworkManager would
result in a fight over the default-route, but more importently
to preserve externally added default-routes on unmanaged interfaces.
NMDefaultRouteManager would ensure that in case of duplicate
metrics, that the device that activated first would keep the
best default-route. It would do so by bumping the metric
of the second device to find a unused metric. The bumping itself
was not very important -- MDefaultRouteManager could also just not
configure any default-routes that show up as second, the result
would be quite similar. More important was to keep the best
default-route on the first activating device until the device
deactivates or a device activates that really has a better
default-route..
Likewise, NMRouteManager would globally manage non-default-routes.
It would not do any bumping of metrics, but it would also ensure that the routes
of the device that activates first are not overwritten by a device activating
later.
However, the `ip route replace` approach has downsides, especially
that it messes with routes on other interfaces, interfaces that are
possibly not managed by NetworkManager. Another downside is, that
binding a socket to an interface might not result in correct
routes, because the route might just not be there (in case of
NMRouteManager, which wouldn't configure duplicate routes by bumping
their metric).
Since commit 77ec302714 we would no longer
use NLM_F_EXCL, but add routes akin to `ip route append`. When
activating for example two ethernet devices with no explict route
metric configuration, there are two routes like
default via 10.16.122.254 dev eth0 proto dhcp metric 100
default via 192.168.100.1 dev eth1 proto dhcp metric 100
This does not only affect default routes. In case of a multi-homing
setup you'd get
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100
192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100
but it's visible the most for default-routes.
Note that we would append the routes that are activated later, as the order
of `ip route show` confirms. One might hence expect, that kernel selects
a route based on the order in the routing tables. However, that isn't
the case, and activating the second interface will non-deterministically
re-route traffic via the new interface. That will interfere badly with
with NAT, stateful firewalls, and existing connections (like TCP).
The solution is to have NMManager keep a global index of the default route-metrics
currently in use. So, instead of determining the default-route metric based solely
on the device-type, we now in addition generate default metrics that do not
overlap. For example, if you activate eth0 first, it gets route-metric 100,
and if you then activate eth1, it gets 101. Note that if you deactivate
and re-activate eth0, then it will get route-metric 102, because the
best route should stick on eth1 (which reserves the range 100 to 101).
Note that when a connection explititly selects a particular metric, then that
choice is honored (contrary to NMDefaultRouteManager which was more concerned
with avoiding conflicts, then keeping the exact metric).
https://bugzilla.redhat.com/show_bug.cgi?id=1505893
(cherry picked from commit 6a32c64d8f)
NMManager will need to know the state of all device at once.
Hence, load it once and cache it in NMConfig.
Note that this wastes a bit of memory in the order of
O(number-of-interfaces). But each device state entry is
rather small, and we always consume memory in the order
of O(number-of-interfaces).
(cherry picked from commit ea08df925f)
The accessor functions just look whether a certain flag is set. As these
functions have a different name then the flags, this is more confusing
then helpful. For example, if you want to know where the NM_GENERATED
flag matters, you had to know to grep for nm_settings_connection_get_nm_generated()
in addition to NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED.
The accessor function hid that the property was implemented as
a connection flag. For example, it was not immediately obvious
that nm_settings_connection_get_nm_generated() is the same
as having the NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED flag
set.
Drop them.
(cherry picked from commit 545e3111c8)
Waiting for carrier on startup is probably the same times that carrier
needs, e.g. on an MTU change. Use the same timing.
Note, that as carrier-wait-timeout is no configurable, this
configuration applies to both -- as the manual page already
claims to do.
(cherry picked from commit 245590bacd)
If the tracked device is a control device only (has no network interface)
like in the case of a cdc-wdm device, get the mtu from the ip interface
(the exposed wwan network interface in this case).
https://bugzilla.redhat.com/show_bug.cgi?id=1460217
(cherry picked from commit efed5254cd)
/proc/sys might be read-only but we want to set it for
enabling shared mode.
Check first if the sysctl already has the expected value,
and if so, do nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=790726
(cherry picked from commit d841930d67)
Also downgrade a few intermediate error logging messages
for failures that happen while start_sharing(). A debug
message is enough in this case, because we propagate now
the error to the caller, which logs a warning anyway.
(cherry picked from commit 3369a2c0b0)
check_and_add_ipv6ll_addr() checks whether a link-local address is
already present in priv->ip6_config and if so, it returns with no
action.
priv->ip6_config is only updated after a merge-and-apply or (in an
idle source) when the external configuration changes and so there is
no guarantee that the addresses there are up-to-date.
priv->ext_ip6_config_captured should be checked instead, because it is
updated from platform right before starting the generation of a
link-local address. Note that also linklocal6_start() already checks
the captured external configuration rather than priv->ip6_config.
https://bugzilla.redhat.com/show_bug.cgi?id=1500350
(cherry picked from commit a7c97d58db)
If a device is 'external' (which means that NM generated an in-memory
connection to only to track the device state) we should not change its
IP configuration.
https://bugzilla.redhat.com/show_bug.cgi?id=1512316
(cherry picked from commit 60334a2893)
In the next commit we will modify ipX_config_merge_and_apply to never
touch external devices. When a "reapply" call is issued on an external
device we are no longer simply tracking its state but we are actively
managing it and so its sys-iface-state must be promoted to managed.
https://bugzilla.redhat.com/show_bug.cgi?id=1512316
(cherry picked from commit 9e41ed4461)
When a master connection is deactivated by user, we set the
autoconnect-blocked reason 'user-request' for the connection and we
propagate the same reason to slaves. Doing so prevents the
autoactivation of slaves when the master is manually activated again,
because the only way to override the 'user-request' blocked reason is
through manual activation of slaves.
Instead what should happen is that the manual deactivation of a master
marks slaves as blocked for failed dependencies. When the master
becomes available again, slaves can autoactivate if the profile allows
it.
https://bugzilla.redhat.com/show_bug.cgi?id=1437598
(cherry picked from commit b31118cfd2)
The _NM_GET_PRIVATE() macro already preserved and propagated
the constness of @self to the resulting private pointer.
_NM_GET_PRIVATE_PTR() didn't do that. Extend the macro,
to make that possible.
(cherry picked from commit bdfdabea51)
Fix the following warning:
src/devices/nm-device.c: In function ‘activation_source_schedule’:
src/devices/nm-device.c:4995:9: error: ‘source_func’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
new_id = g_idle_add (source_func, self);
~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(cherry picked from commit bdfa7d882e)
Don't necessarily fail the entire connection if a duplicate IPv4
address is detected, but instead look at the may-fail property and at
the outcome of IPv6.
https://bugzilla.redhat.com/show_bug.cgi?id=1508001
(cherry picked from commit 14ad1d0cd1)
- split NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN in two parts:
"wrong-pin" and "manual-disconnect". Setting/unsetting them
should be tracked differently, as their reason differs.
- no longer initialize/clear the autoconnect-blocked reasons
during realize/unrealize of the device. Instead, initialize
it once when the object gets created (nm_device_init()), and
keep the settings beyond unrealize/realize cycles. This only
matters for software devices, as regular devices get deleted
after unrealizing once. But for software devices it is essential,
because we don't want to forget the autoconnect settings of
the device instance.
- drop verbose logging about blocking autoconnect due to failed
pin. We already log changes to autoconnect-blocked flags with
TRACE level. An additional message about this particular issue
seems not necessary at INFO level.
- in NMManager's do_sleep_wake(), no longer block autoconnect
for devices during sleep. We already unmanage the device, which
is a far more effective measure to prevent activation. We should
not also block autoconnect.
(cherry picked from commit 3c2b9485a7)
The flags allow for more then two reasons. Currently the only reasons
for allowing or disallowing autoconnect are "user" and "intern".
It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative
meaning. So
nm_device_set_autoconnect_intern (device, FALSE);
gets replaced by
nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN);
and so on.
However, it's chosen this way, because autoconnect shall be allowed,
unless any blocked-reason is set. That is, to check whether autoconnect
is allowed, we do
if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL))
The alternative check would be
if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL)
which seems odd too.
So, add the inverse flags to block autoconnect.
Beside refactoring and inverting the meaning of the autoconnect
settings, there is no change in behavior.
(cherry picked from commit 5279ab5be6)
nm_device_can_auto_connect() only has one caller, auto_activate_device()
in NMPolicy.
That caller already checks whether the connection has autoconnect
enabled, so drop the duplicate check.
This saves some duplication, but it also makes some sense:
NMSettingsConnection has a complex blocking of autoconnect,
so just looking at connection.autoconnect is not enough in
any case to determine whether the connection should autoconnect.
We move thus more handling of autoconnect to NMPolicy, where
it belongs.
(cherry picked from commit 6fff832fe3)
Derived classes should not modify or overwrite this essential behavior
of can_auto_connect(). It doesn't belong to the virtual function.
(cherry picked from commit 715aebe08a)
The number of authentication retires is useful also for passwords aside
802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has
a retry counter and uses a hard-coded value of 3.
Move the setting, so that it can be used in general. Although it is still
not implemented for other settings.
This is an API and ABI break.
Since commit 4a6fd0e83e (device: honor the
connection.autoconnect-retries for 802.1X) and the related bug bgo#723084,
we reuse the autoconnect-retries setting to control the retry count
for requesting passwords.
I think that is wrong. These are two different settings, we should not
reuse the autoconnect retry counter while the device is still active.
For example, the user might wish to set autoconnect-retries to infinity
(zero). In that case, we would retry indefinitly to request a password.
That could be problematic, if there is a different issue with the
connection, that makes it appear tha the password is wrong.
A full re-activation might succeed, but we would never stop retrying
to authenticate. Instead, we should have two different settings for
retrying to authenticate and to autoconnect.
This is a change in behavior compared to 1.8.
Since 32b3eb1181 [core: merge IPv4 and IPv6 implementation of
nm_utils_ip4_property_path()], nm_utils_sysctl_ip_conf_path() introduced
in cd271d5cb1 [core: add nm_utils_sysctl_ip_conf_is_path() util] is used to
cunstruct sysctl paths and it is way less tolerant towards using something
that is not an interface name in the path.
It's always been incorrect to assume the ifname is a linux link name and
it resulted it ugly, if benign, sysctl access attempts such as
"/sys/class/net/28:B2:BD:5D:23:AB/phys_port_id" etc.
Now it triggers an assertion failure. Let's guard all such accesses.
Fixes: 32b3eb1181
Fixes: cd271d5cb1
For a while now, all NMPObject instances are not modified after
being cached. They are immutable, and can be passed around by keeping
a reference to them.
No longer copy the NMPlatformLink data to a @info variable. Instead,
take a reference (which ensures that the instance stays alive). It
won't change, as it's immutable.
The advantage is, that whenever you see a NMPlatformLink pointer,
for exmple in device_recheck_slave_status(), you can be sure that
it's actually a NMPObect, and NMP_OBJECT_UP_CAST() will work.
