The condition in `_get_maybe_ipv6_disabled()` is improperly set which
returns the wrong value on if an device is disabled or not when
generating the assume connection. And when
`/proc/sys/net/ipv6/conf/$DEV/disable_ipv6` is not existed (not
disabling ipv6 through sysctl setting), IPv6 is disabled by default.
Fixes: be655e6ed1 ('core: read "disable_ipv6" sysctl before nm_ip6_config_create_setting()')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1743
Instruct the `NMDnsManager` to emit `CONFIG_CHANGED` signal even
`dns=none` or failed to modify `/etc/resolv.conf`.
The `NMPolicy` will only update hostname when DNS is managed.
Signed-off-by: Gris Ge <fge@redhat.com>
Remove all the code that was added for the CSME coexistence.
The Intel WiFi team can't commit on when, if at all, this feature will
be completely integrated and tested in the NetworkManager.
The preferred solution for now is the solution that involves the kernel
only.
Remove the code that was merged so far.
On very particular timing, if a connection is currently activating
on a modem device and user remove the remote settings associated
an device state change:
prepare -> deactivating (reason 'connection-removed', sys-iface-state: 'managed')
pops before entering into modem_prepare_result, resulting to a crash
on assertion.
We can simply check for the modem state to failed, set the success flag
to FALSE and continue.
Closes: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1354
Signed-off-by: Frederic Martinsons <frederic.martinsons@unabiz.com>
When rolling back a checkpoint, NM will crash due to dereference a NULL
pointer of `priv->removed_devices->len`.
To fix it, we just place a NULL check before that code block.
Fixes: 1f1b71ad9f ('checkpoint: preserve devices that were removed and
readded')
Reference: https://issues.redhat.com/browse/RHEL-1526
Signed-off-by: Gris Ge <fge@redhat.com>
The device authentication request is an async process, it can not know
the answer right away, it is not guarantee that device is still
exported on D-Bus when authentication finishes. Thus, do not return
SUCCESS and abort the authentication request when device is not alive.
https://bugzilla.redhat.com/show_bug.cgi?id=2210271
When we register the auto-activate, the device has to be registered in
NMPolicy, the assertion is correct and ensure that.
This reverts commit 712729f652.
l3cfg emits a log for ACD conflicts. However, l3cfg is not aware of
what are the related NMDevice or the currently active connection, and
so it can't log the proper metadata fields (NM_DEVICE and
NM_CONNECTION) to the journal.
Instead, let NMDevice log about ACD collisions; in this way, it is
possible to get the message when filtering by device and connection.
For example:
$ journalctl -e NM_CONNECTION=d1df47be-721f-472d-a1bf-51815ac7ec3d + NM_DEVICE=veth0
<info> device (veth0): IP address 172.25.42.1 cannot be configured because it is already in use in the network by host 00:99:88:77:66:55
<info> device (veth0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
<warn> device (veth0): Activation: failed for connection 'veth0+'
When a collision is detected by the Address Conflict Detection
mechanism, store the conflicting MAC address in NML3AcdAddrInfo, so
that it is available to listeners of NML3Cfg for events of type
NM_L3_CONFIG_NOTIFY_TYPE_ACD_EVENT.
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')
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')
Parse the access point announced bandwidth in MHz. This is considering
both HT and VHT. Please notice that for VHT 80+80 MHz we are representing it
as 160 MHz.
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
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.
