The full output of the daemon helper is added to a NMStrBuf, without
interpreting it as a string (that is, without stopping at the first
NUL character).
However, when we retrieve the content from the NMStrBuf we assume it's
a string. This is fine for certain commands that expect a string
output, but it's not for other commands as the read-file-as-user one.
Add a new argument to nm_utils_spawn_helper() to specify whether the
output is binary or not. Also have different finish functions
depending on the return type.
(cherry picked from commit 1d90d50fc6)
(cherry picked from commit 59df5fc93f)
When connecting, we add the blobs to the Interface object of the
supplicant. Those blobs are not removed on disconnect and so when we
try to add blobs with the same id, the supplicant returns an error.
Make sure we start from a clean slate on each connection attempt, by
deleting all existing blobs. Probably we should also delete the added
blobs on disconnect, but that's left for a future improvement.
(cherry picked from commit 0093bbd950)
(cherry picked from commit ce3ebf6d3e)
Add a new command to read the content of a file after switching to the
given user. This command can be used to enforce Unix filesystem
permissions when accessing a file on behalf of a user.
(cherry picked from commit 285457a5f8)
(cherry picked from commit 022b992846)
Create a new 'nm-helpers' directory for all the helper programs, to
avoid having too many subdirs in the src directory.
(cherry picked from commit 3d76d12eee)
(cherry picked from commit afa6fc951b)
Add utility functions to get the number of users and the first user
from the connection.permissions property of a connection.
(cherry picked from commit 59543620dc)
(cherry picked from commit 2fc662cc71)
This is needed to ensure that the right CleanupType is chosen when
calling to nm_device_state_changed() a bit later. With this change
CLEANUP_TYPE_REMOVED will be used instead of CLEANUP_TYPE_DECONFIGURE,
which is wrong because the device has already disappeared.
(cherry picked from commit e06aaba1ca)
As we introduced the ipv4.forwarding property in a8a2e6d727 ('ip-config:
Support configuring per-device IPv4 sysctl forwarding option'), we must
not enable or disable the global forwarding setting in the kernel, as it
affects to all the devices, maybe forcing them to behave in a way
different to what the user requested in ipv4.forwarding.
Instead, we need to selectively enable or disable the per-device forwarding
settings. Specifically, only devices activated with ipv4.forwarding=auto
must have their forwarding enabled or disabled depending on shared
connections. Devices with yes/no must not be affected by shared connections.
Also, devices with ipv4.forwarding=auto must get the proper forwarding value
on activation, but also change it when shared connections appear or
disappear dynamically. Use the new sharing-ipv4-change signal from
nm_manager to achieve it.
Fixes: a8a2e6d727 ('ip-config: Support configuring per-device IPv4 sysctl forwarding option')
(cherry picked from commit 32cbf4c629)
This signal notifies about the "sharing state", that's it, when there
is at least one shared connection active or not. Each device informs
to nm_manager when a shared connection is activated or deactivated
and nm_manager emits this signal when the first shared connection is
activated or the last one is deactivated.
For now we're only interested in IPv4 forwarding as it's the only one
that we need to track from nm_device (in following commits).
Fixes: a8a2e6d727 ('ip-config: Support configuring per-device IPv4 sysctl forwarding option')
(cherry picked from commit 8faa33b9d4)
With the ipv4.forwarding property we may modify the forwarding sysctl of
the device on activation. In next commits, we will also modify it if the
connection is shared, instead of modifying the global forwarding.
Restore the forwarding value to the default one when the device is
deconfigured for any reason.
Fixes: a8a2e6d727 ('ip-config: Support configuring per-device IPv4 sysctl forwarding option')
(cherry picked from commit d58d0a793e)
This reverts commit 2ad5fbf025.
It is actually a partial revert. The changes to documentation don't need
to be reverted.
Fixes: 2ad5fbf025 ('policy: refresh IPv4 forwarding after connection activation and disconnection')
(cherry picked from commit f2a2e49d07)
The flag is used for both sleeping and networking disabled conditions.
This is because internally they share logic, but it's not obvious for
users and it has caused confusion in the past when investigating why
devices didn't become managed. Make it explicit that it can be because
of either reason.
It would be better to create two separate flags, actually, and it
doesn't seem complex, but better not to risk introducing bugs for that
little benefit.
Logs before:
device (enp4s0): state change: disconnected -> unmanaged (reason 'unmanaged-sleeping' ...
Logs before:
device (enp4s0): state change: disconnected -> unmanaged (reason 'unmanaged-nm-disabled' ...
(cherry picked from commit 48fc40e1ca)
When we disable networking with `nmcli networking off` the reason that
is logged is "sleeping". Explain instead that networking is disabled.
Before:
device (lo): state change: activated -> deactivating (reason 'sleeping' ...
After:
device (lo): state change: activated -> deactivating (reason 'networking-off' ...
(cherry picked from commit f6d6a7e2eb)
When we do `nmcli networking off` it's shown as state "sleeping". This
is confusing, and the only reason is that we share internally code to
handle both situations in a similar way.
Rename the state to the more generic name "disabled", situation that can
happen either because of sleeping or networking off.
Clients cannot differentiate the exact reason only with the NMState value,
but better that they show "network off" as this is the most common reason
that they will be able to display. If the system is suspending, there will
be only a short period of time that they can show the state, and showing
"network off" is not wrong because that's what NM has done as a response
to suspend.
In the logs, let's make explicit the exact reason why state is changing
to DISABLED: sleeping or networking off.
Logs before:
manager: disable requested (sleeping: no enabled: yes)
manager: NetworkManager state is now ASLEEP
Logs after:
manager: disable requested (sleeping: no enabled: yes)
manager: NetworkManager state is now DISABLED (NEWORKING OFF)
State before:
$ nmcli general
STATE ...
asleep ...
State after:
$ nmcli general
STATE ...
network off ...
(cherry picked from commit 3355ba9380)
This property allows the user to optionally configure
an interlink name on a HSR interface, so that it could
serve as RedBox (Redundant Box) by connecting DAN (dual
attachment node) to SAN (single attachment node).
(cherry picked from commit 69d0fb161e)
Uses the `hsr.protocol-version` property defined in the previous
commit to configure the property in the kernel.
(cherry picked from commit 0b99629278)
This property allows the user to set the protocol
version when using HSR. Currently, the property
supports two values - `2010` (referred to as HSRv0
in the kernel), and `2012` (HSRv1).
(cherry picked from commit 9a2395c779)
Adds support for reapplying the `sriov.vfs` property. Note this
does not include `num_vfs`, as the configuration needs to be reset
and reconfigured from scratch in that case.
Previously, if an existing VF is modified (e.g. if we change the `trust`
flag), we reset all VF configurations, and started from scratch. But in
some cases, this is unnecessarily disruptive.
Resolves: https://issues.redhat.com/browse/RHEL-95844
(cherry picked from commit 4ba3ffee67)
Document a known limitation that we delete bridges and ports from ovsdb
when we remove their last NM-owned attached port or interface, even if
other externally added ports or interfaces exist.
(cherry picked from commit 86ea2c5963)
The commit linked below introduced a bug that caused that OVS ports
added externally to NM are always deleted when we delete any OVS
interface. It affects to all externally added ports, including those
that are not related to the deleted interface and even those in
different OVS bridges.
Fix it by only modifying ports and bridges that are ascendants of the
deleted interface, leaving everything else untouched.
Note that bridges and ports still need to have at least one NM-managed
interface, otherwise they will also be purged. For example, an NM-owned
OVS bridge with 2 ports+iface, one NM-owned and one external: if we
delete the NM-owned iface, both ports and the bridge will be deleted.
For now, this is a known limitation that is not being fixed here.
Fixes: 476c89b6f2 ('ovs: only keep bridges and ports with NM interfaces attached')
(cherry picked from commit 93491d76ec)
If "flags" indicate that only secrets should be serialized and a peer
doesn't contain any secrets, skip it. Otherwise the function would
return a non-empty result when the connection contains no secret,
which causes issues later in the agent manager.
Fixes: e148ec07d5 ('libnm: add NMWireGuardPeer and libnm support for peers')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2244
(cherry picked from commit 86c7f1ed14)
During disposal we're calling to remove_all_aps that in turns schedules
an auto-activate recheck. As the device is removed, this triggers an
assertion when trying to do the recheck.
Fix that by not scheduling the recheck.
Example of backtrace that this commits fix:
0 __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
1 0xf746e270 in __pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=<optimized out>) at pthread_kill.c:43
2 0xf743fbc6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
3 0xf7431614 in __GI_abort () at abort.c:79
4 0xf775afea in g_assertion_message (domain=domain@entry=0x209a9f "nm", file=file@entry=0x1f7d59 "../NetworkManager-1.43.7/src/core/nm-policy.c", line=line@entry=1665,
func=func@entry=0x1f94d9 <__func__.6> "nm_policy_device_recheck_auto_activate_schedule",
message=message@entry=0x1d3e950 "assertion failed: (g_signal_handler_find(device, G_SIGNAL_MATCH_DATA, 0, 0, NULL, NULL, NM_POLICY_GET_PRIVATE(self)) != 0)")
at ../glib-2.72.3/glib/gtestutils.c:3253
5 0xf775b05e in g_assertion_message_expr (domain=0x209a9f "nm", file=0x1f7d59 "../NetworkManager-1.43.7/src/core/nm-policy.c", line=1665,
func=0x1f94d9 <__func__.6> "nm_policy_device_recheck_auto_activate_schedule",
expr=0x1f8afc "g_signal_handler_find(device, G_SIGNAL_MATCH_DATA, 0, 0, NULL, NULL, NM_POLICY_GET_PRIVATE(self)) != 0") at ../glib-2.72.3/glib/gtestutils.c:3279
6 0x0005f27a in nm_policy_device_recheck_auto_activate_schedule (self=0x1d3e950, device=0x209a9f) at ../NetworkManager-1.43.7/src/core/nm-policy.c:1679
7 0x000548ae in nm_manager_device_recheck_auto_activate_schedule (self=<optimized out>, device=<optimized out>) at ../NetworkManager-1.43.7/src/core/nm-manager.c:3113
8 0x00070622 in nm_device_recheck_auto_activate_schedule (self=<optimized out>) at ../NetworkManager-1.43.7/src/core/devices/nm-device.c:9249
9 0xf693aa8c in ap_add_remove (self=self@entry=0x1ceb0b0, is_adding=0, ap=<optimized out>, recheck_available_connections=0)
at ../NetworkManager-1.43.7/src/core/devices/wifi/nm-device-wifi.c:846
10 0xf693bcda in remove_all_aps (self=self@entry=0x1ceb0b0) at ../NetworkManager-1.43.7/src/core/devices/wifi/nm-device-wifi.c:863
11 0xf693f83c in dispose (object=0x1ceb0b0) at ../NetworkManager-1.43.7/src/core/devices/wifi/nm-device-wifi.c:3809
12 0xf7806e72 in g_object_unref (_object=<optimized out>) at ../glib-2.72.3/gobject/gobject.c:3636
13 g_object_unref (_object=0x1ceb0b0) at ../glib-2.72.3/gobject/gobject.c:3553
14 0x000f7fa4 in _nm_dbus_object_clear_and_unexport (location=location@entry=0xffa50644) at ../NetworkManager-1.43.7/src/core/nm-dbus-object.c:203
15 0x000576e4 in remove_device (self=self@entry=0x1c9c900, device=<optimized out>, quitting=quitting@entry=1) at ../NetworkManager-1.43.7/src/core/nm-manager.c:2289
16 0x0005a864 in nm_manager_stop (self=self@entry=0x1c9c900) at ../NetworkManager-1.43.7/src/core/nm-manager.c:7784
17 0x00023438 in main (argc=<optimized out>, argv=<optimized out>) at ../NetworkManager-1.43.7/src/core/main.c:530
Fixes: 96f40dcdcd ('wifi/ap: explicitly unexport AP and refactor add/remove AP')
Fixes: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1791
(cherry picked from commit 3904135150)
In some cases it is necessary to set a custom DHCP client-id during
early boot. For example, the firmware of some InfiniBand NIC uses a
48-bit MAC derived from the InfiniBand 20-byte MAC when doing
PXE. NetworkManager doesn't have any knowledge of that 48-bit MAC and
uses the full MAC as client-id, therefore getting a different lease.
Introduce a new option 'rd.net.dhcp.client-id' to specify a custom
client-id.
Resolves: https://issues.redhat.com/browse/RHEL-108454https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2277
(cherry picked from commit 40aa27690c)
When reading NetworkManager.conf and NetworkManager-intern.conf we might
need to know if a group is defined or not, even if it's empty. This is
the case, for example, for [global-dns]. If [global-dns] is defined in
NM.conf overwrites the config from NM-intern, and if it's defined in any
of them they overwrite the configs from connections.
Before this patch, defining it as an empty group was ignored:
```
[global-dns]
```
Instead, it was necessary to add at least one key-value to the group.
Otherwise the group was silently ignored.
```
[global-dns]
searches=
```
Keep empty groups so we can take better decissions about overwritting
configs from other sources.
(cherry picked from commit 4a46f454da)
Clients like nmstate needs to know if the [global-dns] section is
defined or not, so they know if DNS configs from connections are
relevant or not. Expose it in D-Bus by always exposing "searches"
and "options" if it's defined, maybe as empty lists.
(cherry picked from commit 7fb4724efa)
According to the documentation, settings from [global-dns] (searches and
options) are always merged with those from connections. However this was
not happening if no [global-dns-domain-*] exists, in which case
connections were ignored. This happened because in the past both global
sections must de defined or undefined. When this was changed to allow
defining only [global-dns], allowing it in the function that generates
the resolv.conf file was forgotten. Fix that now.
Anyway, merging these configs doesn't make much sense. The searches and
options defined in connections probably make sense only for the nameservers
defined in that same connection.
Because of this, make the following change: if global nameservers are
defined, use searches and options from [global-dns] only, because those
defined in connections may not make sense for the global nameservers. If
[global-dns] is missing, assume an empty [global-dns] section.
Also, if no global nameservers are defined, but [global-dns] is, make
that it overwrites the searches and options defined in connections. This
is not ideal, but none of the alternatives is better and at least this
is easy to remember.
So, the resulting rules from above are:
- If [global-dns] is defined, it always overwrite searches and options
from connections.
- If [global-dns-domain-*] is defined, it always overwrite nameservers
from connections. It overwrites searches and options too.
Fixes: 1f0d1d78d2 ('dns-manager: always apply options from [global-dns]')
Fixes: f57a848da5 ('man: update documentation about global DNS configuration')
(cherry picked from commit 1cba0a3cca)
Since 1.44 we accept a global-dns section without any global-dns-domain
section, so users can define searches and options without defining any
global DNS servers.
When set from the D-Bus API it was still rejected. Fix it.
Fixes: 1f0d1d78d2 ('dns-manager: always apply options from [global-dns]')
(cherry picked from commit 294131a2a4)
NM_SETTING_BOND_OPTION_LACP_ACTIVE is flagged as BOND_OPTFLAG_IFDOWN in
the kernel and hence should not be in OPTIONS_REAPPLY_SUBSET.
Authored-by: Mohith Kumar Thummaluru <mohith.k.kumar.thummaluru@oracle.com>
Signed-off-by: Mohith Kumar Thummaluru <mohith.k.kumar.thummaluru@oracle.com>
Signed-off-by: Pradyumn Rahar <pradyumn.rahar@oracle.com>
(cherry picked from commit 9c48bae3b2)
Unrealized software devices are always available for activation,
hardware devices never.
In nm_manager_get_best_device_for_activation() we call
nm_device_is_available() on candidate devices. Without this fix, any
unrealized software device would be not considered ready for
activation, which is wrong.
A software device can override the default implementation of
is_available(). For example NMDeviceOvsInterface does that and only
checks the OVSDB is ready.
Fixes: ba86c208e0 ('Revert "core: prevent the activation of unavailable OVS interfaces only"')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2253
(cherry picked from commit 8b26cb35ee)
The test calls g_main_context_ref() on client_context, which must then
be unreferenced.
Fixes: 88724ff169 ('libnm: add nm_client_wait_shutdown() function for cleaning up NMClient')
(cherry picked from commit d559f61423)
With the newer glib and libc in F42 and Ubuntu devel, the
"{left,right} double quotation mark" characters are printed in the
output message. The double quotation marks are multi-byte characters
and they can't be matched using a character class []. Update the
regexp accordingly.
(cherry picked from commit 5ad712974e)
When a software device becomes deactivated, we check whether it can
be unrealized (= deleted in kernel), by calling function
delete_on_deactivate_check_and_schedule().
The function returns without doing anything if there is a new
activation enqueued on the device (priv->queued_act_request), because
in that case the device will be reused for the next activation.
This commit fixes a problem seen in NMCI test
@ovs_delete_connecting_interface: sometimes the device is not
unrealized after deleting the connection. That happens because if the
queued activation fails, we never try again to unrealize the device.
Fix that by calling delete_on_deactivate_check_and_schedule() when
there is a failure starting the queued activation.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2258
(cherry picked from commit 0b03614b68)
This adds simple unit tests for most common NBFT deployments.
Sample data were mostly taken from the upstream libnvme repository.
(cherry picked from commit dce149352d)
There are several flags specified in the NVMe Boot Specification
that may indicate DHCP was used to acquire information during the
pre-OS phase. This commit considers these additional sources,
based on actual NBFT table contents from different systems.
Although we've seen slight variations in firmware implementations
regarding the HFI IP Origin values when DHCP was configured, the
new set of rules still align with expectations.
(cherry picked from commit 6304d51440)
