When updating NetworkManager to a new version, normally the service is
not restarted by the installer to avoid interrupting networking.
However, next nmcli invocation will use the updated version, but against
the older version of the daemon that is still running. Although this is
suposed to work, it is advisable that nmcli and daemon's versions are
the same. Emit a warning recommending restarting the daemon.
Add nmcli test to check the new feature. To avoid breaking the existing
tests, test-networkmanager-service now reports the same version than the
running nmcli except if it's instructed to report a different one.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1703
(cherry picked from commit fb851f3294)
When a device belonging to a checkpoint is removed, we clear the
device pointer from the DeviceCheckpoint and move the object from the
devices list to the removed-devices list of the checkpoint.
Later, when restoring the connection we need to set again the device
pointer in DeviceCheckpoint; otherwise, any connection on that device
can't be reactivated if changed.
Fixes: 0e2f7ac7b5 ('nm-checkpoint: drop reference to NM_DEVICE objects on removal signal')
(cherry picked from commit b80a398306)
With flag DISCONNECT_NEW_DEVICES, on rollback we delete devices that
are present in the system and are not in the checkpoint.
The problem is that we remove the device from
`NMCheckpointPriv->devices` when it is deleted and so we lose the
information that the device was in the checkpoint. We need to also
look in the `removed_devices` list.
Fixes: 0e2f7ac7b5 ('nm-checkpoint: drop reference to NM_DEVICE objects on removal signal')
(cherry picked from commit 0fcfd6e24f)
Software devices that are controllers like bond/bridge/team when
configured to not ignore carrier are being deleted when deactivating the
device. Software devices that are not controllers, shouldn't be deleted.
Otherwise, if a VLAN link is deleted because the ethernet carrier-change
then NetworkManager won't be able to reactivate the VLAN once the
ethernet gets carrier because the link is not present.
This is restoring the previous behaviour and it's know to be relied on
by users.
https://bugzilla.redhat.com/show_bug.cgi?id=2224479https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1701
Fixes: efa63aef3a ('device: delete software device when software devices lose carrier')
Move the warning about the presence of ifcfg-rh profiles from the
plugin to NMSettings. In this way, it will be easier to implement the
migration option in the next commit.
When activating a port connection it will require the controller
connection is active or a valid controller device candidate is available
for activation.
One of the conditions we consider for a controller device to be a valid
candidate for the connection is that it is not active, therefore we
should also consider as valid a device that is currently deactivating.
Otherwise, we could fail during the port activation just because the
deactivation of the controller device candidate didn't finish yet.
https://bugzilla.redhat.com/show_bug.cgi?id=2125615https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1693
Kernel's dev_valid_name() calls isspace(), which also rejects '\v'
and '\240'.
As this tightens the check, the change can break code that partly worked
before. It surely didn't work to the point, where an interface with such
name could be created in kernel.
# ip link add name $'foo\240bar' type dummy
RTNETLINK answers: Invalid argument
If --offline and --ask were used at the same time, and endless loop
showing the readline's prompt but without waiting for user's input
happened.
This was because when using --offline, all arguments are parsed and
resolved before running the g_main_loop. In nmc_readline_helper it was
checked that the main loop is running, so if g_main_loop_quit is called
we can stop waiting for user's input.
Fix this bug by continue polling for user input if the main loop is
running or if we are in offline mode. Cancelling the user input is
still possible both in normal and offline mode with Ctrl+C or Ctrl+D.
Added a test case to verify that this still works after future changes.
This flag is a setting that changes the behaviour of nmcli, it's not
only the current state of the program, so it makes more sense to put it
in NmcConfig than in NmCli.
Furthermore, it's needed to fix a bug in next commit, too.
The `nm_device_hw_addr_reset()` should only set MAC address on NIC
with valid(>0) interface index.
The failure was found by `ovs_mtu` test of NMCI, failed to reproduce
the original problem (`ovs_mtu` test of NMCI) with 100 times retry.
And no trace log found for original test failure, hence cannot tell why
`nm_device_hw_addr_reset()` been invoked with iface index 0.
Signed-off-by: Gris Ge <fge@redhat.com>
We delete devices when the connection goes down and NetworkManager
created the device earlier.
Software devices like bond/bridge/team default to ignoring carrier.
However, when configuring them to not ignore carrier
([device].ignore-carrier), they were not deleted when deactivating the
devices.
This adjusts commit d0c2a24b71 ('device: do not remove software devices
on initial disconnected (rh #1035814)'). Note that back then there was
no check whether the device has an activation queued, so it behaved
differently then.
When the software device enters the UNAVAILABLE state from UNMANAGED,
during cleanup we shouldn't delete the link.
Co-Authored-By: Beniamino Galvani <bgalvani@redhat.com>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1686
When matching two connections one might be using UUID and the other one
could be using interface-name for the controller property. When
recovering from a fresh start NM does not have any context and when
generating a connection we are using UUID as the controller.
It is always hard to guess what is the right candidate to pick but at
least something NM can do is checking if the UUID matches a connection
with the same controller interface-name. If there are no other
conflicts, then we can assume that is a good canditate to activate.
This is a follow up to `dc254f90e2b306700a0b81f7194e9b0438c62f4c`.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1684
The default behavior is not to rename profiles. I guess, that makes
sense, as renaming a file when changing the "connection.id" could break
users who rely on the name.
My use case is the following. When I connect a Wi-Fi hotspot I use
`nmcli device wifi connect $SSID`, which -- as expected -- persists the
profile to "/etc/NetworkManager/system-connections/$SSID.nmconnection".
Later, I always update the profile's name to "w_$SSID" so I can see on
the name that this is wireless profile. I also want the filename to
reflect that change of name.
Add a configuration option for that. All the infrastructure
("force_rename" parameter) already exists.
There was already a force_rename argument to nms_keyfile_writer_connection(), which
-- if TRUE -- means to always rename the file, if it exists.
What we also want, is to follow the change of a connection.id. So we don't want
to force a rename, if we already use the preferred name, but we also want to rename
otherwise.
Extend the boolean "force_rename" argument to a NMTernary, where NM_TERNARY_DEFAULT
now means to follow the preferred name.
"force_rename" parameter was not used previously, but it also was broken.
Fix it. We need to create a new NMSettingsStorage instance when the filename
changes, as the storage's filename is immutable.
No bad effects so far, it was unused.
But as it wasn't used, also no longer set the update_reason flag
NM_SETTINGS_CONNECTION_UPDATE_REASON_FORCE_RENAME. We didn't have the
force-rename behavior so far. This makes the flag totally unused, and
maybe should be dropped. It's kept for now, if only to show what could
be done.
We have some interal code that is only used to expose functionality for
the tests. Those functions should be easily distinguishable from code
that is used by the "real" code. Give a "nmtst" prefix. Rename
nms_keyfile_writer_test_connection() to nmtst_keyfile_writer_test_connection().
When user are changing SR-IOV VF settings for options like `max-tx-rate`
which some hardware not supported yet, the failure of this VF will fail
the whole activation, then the SR-IOV will be disabled means all the VFs
will be deleted.
Deleting VFs might break network connectivity and this collateral
damage of VF option failure is not acceptable for OpenShift use cases
even they have checkpoint protection.
This patch only log warn message on failure of VF options and will not
fail the activation.
NetworkManager also ignore MTU failure during activation, I believe this
fit into the same assumption.
User case reference: https://bugzilla.redhat.com/show_bug.cgi?id=2210164
Signed-off-by: Gris Ge <fge@redhat.com>
Fail to save a connection with a 'link' setting instead of just
ignoring it. Now:
$ nmcli connection add type ethernet ifname foobar
Connection 'ethernet-foobar' (c3f6f067-e1d5-4bb1-8d67-e09109253a79) successfully added.
$ nmcli connection modify ethernet-foobar link.tx-queue-length 1234
Error: Failed to modify connection 'ethernet-foobar': failed to update connection: The ifcfg-rh plugin doesn't support setting 'link'. If you are modifying an existing connection profile saved in ifcfg-rh format, please migrate the connection to keyfile using 'nmcli connection migrate c3f6f067-e1d5-4bb1-8d67-e09109253a79' or via the Update2() D-Bus API and try again.
$ nmcli connection migrate c3f6f067-e1d5-4bb1-8d67-e09109253a79
Connection 'ethernet-foobar' (c3f6f067-e1d5-4bb1-8d67-e09109253a79) successfully migrated.
$ nmcli connection modify ethernet-foobar link.tx-queue-length 1234
$
Fixes: 39bfcf7aab ('all: add "link" setting')
The ifcfg-rh plugin is now deprecated and in bugfixes-only mode. When
users try to set a property that is not supported by the plugin, we
need to report an error.
Add an helper function to set such error. Also, introduce a new error
code so that the situation can be detected and dealt with
programmatically.
Rename the variables and function name to use conscious language. In
addition, rename `type` and `link_type` variables to `port_type` and
`controller_type` to make it more intuitive.
When configuring the bridge port options the code was checking on port
link type instead of controller link type. In addition, the test is now
being skipped for nm-fake-platform.
The macro uses g_alloca(). Using alloca() is potentially dangerous. For
example, it must never be used in an unbounded loop. This should be
immediately obvious from the name, so we don't accidentally use them
in the wrong context.
All other alloca() macros should have such a prefix already. And they
always have to be macros, because you couldn't use alloca() to return
memory from a function.
We want to guard against concurrent modifications of profiles. We cannot
lock profiles, so what we instead do is expose (and bump) a version ID.
The user can check the version ID, plan ahead what to do, and tell
NetworkManager to only make the modification if no concurrent
modification was done. The conflict can be detected via the version ID.
The Update2() D-Bus call gets a parameter to only allow the request if
the version ID still matches.
nmcli should use this, but it is quite some effort to retry upon
concurrent modification. This is still to do.
Note that the user might make a decision that is based on multiple
profiles. As the new version-id is only per-profile, we cannot guard
against such inter-profile modifications. What would be needed, is a
UpdateMany() call, where we could modify multiple profiles at once, and
the action only takes effect if all version IDs show no concurrent
modification. That's not done yet, and maybe never will be.
By default, bond/bridge/team devices ignore carrier, and so do their
ports. However, it can make sense to set '[device*].ignore-carrier' for
the controller device. Meaningfully support that.
This is a follow up to commit 8c91422954 ('device: handle carrier
changes for master device differently'), which didn't fully solve the
problem.
What already works, is that when you set ignore-carrier for the
controller, then after loss of carrier and a carrier wait timeout, the
controller and ports go down. If both the controller and port profiles
have autoconnect disabled, they stay down and that's it. It works as
expected, but is not very useful, because when we want to automatically
react on carrier loss, we also want to automatically reconnect.
For controller profiles, carrier only makes sense when ports are
attached. However, we can (auto) activate controller profiles without
ports. So when the user enables autoconnect for the controller profile,
then the profile will eagerly reconnect. That means, after loss of
carrier, the device goes down and reconnects right away. It means, when
configuring a bond with ignore-carrier=no and autoconnect=yes, then
the sensible thing happens (an immediate reconnect). That is just not
a useful configuration.
The useful way to configure configure ignore-carrier=no for a controller
device, autoconnect on the master must be disabled while being enabled
on the ports. After all, it's the ports that will autoconnect based on
the carrier state and bring up the controller with them.
Note that at the moment when a port decides to autoconnect, the
controller profile is not yet selected. That only happens later during
_internal_activate_device() after searching it with find_master(). At
that point, the port profile checks whether it should autoconnect based
on its own carrier state, and abort if not.
If autoconnect is aborted due to lack of carrier, the profile gets
blocked from autoconnect with reason "failed". Hence, when the carrier
returns, we need to clear any "failed" blocked reasons and schedule
another autoconnect check,
Note that this really only works if the port is itself a simple device,
like an ethernet. If the port is itself a software device (like a bond,
or a VLAN), then the carrier state in _internal_activate_device() is
unknown, and we cannot avoid autoconnect. It's unclear how that could
make sense, if at all.
This setup can be combined with "connection.autoconnect-slaves=yes". In
that case, we have the first port to autoconnect when they get carrier,
bringing up the controller too. Usually the other ports that don't have
carrier would not autoconnect, but with autoconnect-slaves they will.
The effect is, that we autoconnect whenever any of the ports has
carrier, and then we immediately also bring up the ports that don't have
carrier (which we usually would not).
https://bugzilla.redhat.com/show_bug.cgi?id=2156684https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1658
Between ppp 2.4.8 and 2.4.9, "rp-pppoe.so" was renamed to "pppoe.so" (and a
symlink created). Between 2.4.9 and 2.5.0, the symlink was dropped.
See-also: b2c36e6c0e
I guess, NetworkManager always meant to use ppp's "(rp-)pppoe.so"
plugin, and never the library from the rp-pppoe project.
If a user actually wants to use the plugin from rp-pppoe project, then
this is going to break.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1312
Fixes: afe80171b2 ('ppp: move ppp code to "nm-pppd-compat.c"')
Previously, the ppp version was only detected (and used) at one place,
in "nm-pppd-compat.c", after including the ppp headers. That was nice
and easy.
However, with that way, we could only detect it after including ppp
headers, and given the ugliness of ppp headers, we only want to include
them in "nm-pppd-compat.c" (and nowhere else).
In particular, 'nm-pppd-compat.c" uses symbols from the ppp daemon, it
thus can only be linked into a ppp plugin, not in NetworkManager core
itself. But at some places we will need to know the ppp version, outside
of the ppp plugin and "nm-pppd-compat.c".
Additionally, detect it at configure time and place it in "config.h".
There is a static assert that we are in agreement with the two ways of
detection.
