Control it with a new NM_DEVICE_MANAGED_SET_ADMIN_STATE flag.
This flag will make that, at the same time that the device is moved to
managed/unmanaged, it's admin state is set to up/down. Many users want
to have a way to have their devices in a DOWN admin state when they are
not using them. Because of the complex activation process, NM wants to
have its devices in UP state all the time. However, it is not a problem
to have it DOWN if we are not managing it.
(cherry picked from commit b9725dab73)
(cherry picked from commit 49ed0efc3c)
Previous commits added the capability to persist to disk the value of
'managed' received via the D-Bus API. Users might need to clear the
previous content, thus reseting it to its default.
Although this is specially useful for the PERMANENT flag, we need to be
consistent and reset the runtime state too.
(cherry picked from commit f346fcf977)
(cherry picked from commit 82a586454b)
If the NM_DEVICE_MANAGED_FLAGS_PERMANENT flag is used, the value will be
stored to disk, to the NetworkManager-intern.conf file, in a [device-*]
section.
To modify the runtime value, the NM_DEVICE_MANAGED_FLAGS_RUNTIME must be
passed. This allows to control independently whether to modify only one
or both.
(cherry picked from commit ec1522fa8c)
(cherry picked from commit 47efc0e17e)
To support setting devices as managed or unmanaged via D-Bus API in a
permanent way, we need a way to store this configuration on disk. Before
this commit, only config files manually edited allowed it. Following
commits will make use of the new functions to store [device-*] sections
into NetworkManager-intern.conf depending on D-Bus method invocations.
(cherry picked from commit 0a1503f052)
(cherry picked from commit e47bf2efac)
Now it is possible to have [.intern.device-*] sections in
NetworkManager-intern.conf. Take them into account when parsing the
configuration keyfiles.
(cherry picked from commit 47c1b04f9e)
(cherry picked from commit 9a09359a01)
The 'Managed' property only sets the managed state in runtime, but it is
not possible to persist it to disk. Add a SetManaged method that will be
able to persist it to disk. In this commit, it just modify the runtime
state, so it actually only does the same than setting the property.
Storing to disk will be added in next commits.
(cherry picked from commit 9ff530c322)
(cherry picked from commit 4cd37cc464)
Added support for the following properties in connection profile:
id (VNI), remote IPv4/IPv6, ttl, tos, df, destination port.
See IP-LINK(8) manual page with command `man 8 ip-link` for more details
on the properties. See also previous commit for nm supported attributes.
id and remote are mandatory attributes:
```
$ nmcli connection add type geneve save no
Error: 'id' argument is required.
$ nmcli connection add type geneve id 42 save no
Error: 'remote' argument is required.
```
(cherry picked from commit 2aaf88375e)
(cherry picked from commit 19fb2c0d1f)
GENEVE (Generic Network Virtualization Encapsulation) is a network
tunneling protocol that provides a flexible encapsulation format for
overlay networks. It uses UDP as the transport protocol and supports
variable-length metadata in the tunnel header.
This patch adds GENEVE tunnel to NM's platform layer:
- Add platform API functions (nm_platform_link_geneve_add,
nm_platform_link_get_lnk_geneve)
- Netlink message parsing for the following attributes:
* IFLA_GENEVE_ID - VNI (Virtual Network Identifier)
IPv4 and IPv6 remote
* IFLA_GENEVE_REMOTE
* IFLA_GENEVE_REMOTE6
TTL, TOS, and DF flags
* IFLA_GENEVE_TTL
* IFLA_GENEVE_TOS
* IFLA_GENEVE_DF
UDP destination port
* IFLA_GENEVE_PORT
- Add test cases for GENEVE tunnel creation and detection with two test
modes covering IPv4 and IPv6.
The implementation tries to follow the same patterns as other tunnel
types (GRE, VXLAN, etc.) and integrates with the existing platform
abstraction layer.
(cherry picked from commit 29c8bbe21a)
(cherry picked from commit b071b0fafa)
In kernel, the onlink flag (RTNH_F_ONLINK) is associated with each
nexthop (rtnh_flags) rather than the route as a whole. NM previously
stored it only per-route in NMPlatformIPRoute.r_rtm_flags, which meant
that two nexthops only differing with the onlink flag were combined
as one entry in the platform cache.
Fix this by tracking the onlink flag per-nexthop.
Resolves: https://issues.redhat.com/browse/NMT-1486
(cherry picked from commit d564a0c3f9)
(cherry picked from commit 8af56448c8)
When authenticating via 802.1X, the supplicant must be made aware of
the bridge the interface is attached to. This was already done for
wifi in commit ae31b4bf4e ('wifi: set the BridgeIfname supplicant
property when needed'). When setting the BridgeIfname property, the
supplicant opens an additional socket to listen on the bridge, to
ensure that all incoming EAPOL packets are received.
Without this patch, the initial authentication usually works because
it is started during stage2 (prepare), when the device is not yet
attached to the bridge, but then the re-authentication fails.
Note: I could reproduce the problem only when the bridge is configured
with bridge.group-forward-mask 8.
Resolves: https://issues.redhat.com/browse/RHEL-121153https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2301
(cherry picked from commit 965aa81027)
Restrict connectivity check DNS lookups to just the relevant link if the link
has a per-link DNS resolver configured. This change was previously discussed as
part of issue
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1836, and
brings NM's behavior back in line with the behavior documented in the man page.
The connectivity check checks for a per-link DNS resolver by querying
systemd-resolved's `ScopeMask` for the link; this involves a small D-Bus
roundtrip, but is ultimately the more flexible solution since it is also capable
of dealing with per-link DNS configuration stemming from other sources.
Fixes: e6dac4f0b6 ('core: don't restrict DNS interface when performing connectivity check')
(cherry picked from commit 6e2de1d2b3)
(cherry picked from commit 4610511bcd)
When connecting to a wifi network and providing the password on the
command line, nmcli first looks if there is a compatible connection to
reuse. If there is not, it creates and activates a new one via a
single call to AddAndActivate().
If there is a compatible connection, nmcli first calls Update() on it
to set the new password and then Activate() to bring it up. Before
that, it registers a secret agent that can prompt for a new password
in case of authentication failure.
However, as soon as nmcli registers a secret agent, NM tries to
activate again the connection if it was blocked due to a previous
authentication failure. This connection attempt is going to fail
because it still uses the old password, as new one hasn't been set via
Update().
Change the order of operations to register the agent after Update()
and before Activate().
Reproducer:
nmcli device wifi connect SSID password BAD_PASSWORD
nmcli device wifi connect SSID password GOOD_PASSWORD
Fixes: c8ff1b30fb ('nmcli/dev: use secret agent for nmcli d [wifi] connect')
(cherry picked from commit 427a7cf257)
(cherry picked from commit d399ffbaba)
Executing this command twice, or when a connection profile already
exists for the SSID:
nmcli device wifi connect $SSID password $PASSWORD
returns error:
Error: 802-11-wireless-security.key-mgmt: property is missing.
When setting the password nmcli was wiping the existing wireless
security setting.
Fixes: c8ff1b30fb ('nmcli/dev: use secret agent for nmcli d [wifi] connect')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1688
(cherry picked from commit 3a4e18e302)
(cherry picked from commit 50387acd4b)
The D-Bus API documentation of the IPv4 and IPv6 settings say:
* addresses
Deprecated in favor of the 'address-data' and 'gateway'
properties, but this can be used for backward-compatibility
with older daemons. Note that if you send this property the
daemon will ignore 'address-data' and 'gateway'.
* gateway
The gateway associated with this configuration. This is only
meaningful if "addresses" is also set.
This documentation wrongly suggests that at D-Bus level "gateway"
requires "addresses", while it actually requires "address-data". The
reason for the inconsistency is that the gateway documentation is
common between nmcli and D-Bus and it refers to the "address" GObject
property, not to the D-Bus property.
Fix this inconsistency by not explicitly mentioning the property name.
Fixes: 36156b70dc ('libnm: Override parts of nm-setting-docs.xml')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2319
(cherry picked from commit dad4da06b1)
(cherry picked from commit 102c763348)
The function strerror_r returns an int per POSIX spec, but GNU version
returns char *. Using it fails the compilation in Alpine, so use
_nm_strerror_r instead that handles both cases.
Fixes: 41e28b900f ('daemon-helper: add read-file-as-user')
(cherry picked from commit 599cc1ed1d)
(cherry picked from commit ea759ccf3a)
In the past, stable branches used odd micro numbers as development micro
version. Because of that, NM_API_VERSION was defined with MICRO+1 so we
don't get warnings during development.
As we stopped using odd micro=devel it is wrong to set MICRO+1 on odd
releases. Final users of 1.52.3 has NM_API_VERSION 1.52.4.
However, during development we need to have MICRO+1. For example, if we
are working on top of 1.52.3 towards the next 1.52.4, we define new
symbols with NM_AVAILABLE_IN_1_52_4. Because of that, we get compilation
failures until we finally bump to 1.52.4, just before the release. The
CI remains red until then, potentially missing many bugs.
For now, just set MICRO+1 all the time. It is wrong, but it was wrong
half of the time anyway, and at least we'll have a green CI until we
implement a definitive solution.
(cherry picked from commit 13bfa44ceb)
Add a new public function nm_utils_copy_cert_as_user() to libnm. It
reads a certificate or key file on behalf of the given user and writes
it to a directory in /run/NetworkManager. It is useful for VPN plugins
that run as root and need to verify that the user owning the
connection (the one listed in the connection.permissions property) can
access the file.
(cherry picked from commit 1a52bbe7c9)
(cherry picked from commit 3d85bace3d)
The new API indicates that the VPN plugin supports reading files
(certificates, keys) of private connections in a safe way
(i.e. checking user permissions), or that it doesn't need to read any
file from disk.
(cherry picked from commit 10db4baeb6)
(cherry picked from commit 8437e14758)
If we add a new property in the future and it references a certificate
or key stored on disk, we need to also implement the logic to verify
the access to the file for private connections.
Add a new property flag NM_SETTING_PARAM_CERT_KEY_FILE to existing
certificate and key properties, so that it's easier to see that they
need special treatment. Also add some assertions to verify that the
properties with the flag are handled properly.
While at it, move the enumeration of private-files to the settings.
(cherry picked from commit acbfae5e051af8647e32d14ccc6be05419dcca77)
(cherry picked from commit e3c27f2a22)
In case of private connections, the device has already read the
certificates and keys content from disk, validating that the owner of
the connection has access to them. Pass those files as blobs to the
supplicant so that it doesn't have to read them again from the
filesystem, creating the opportunity for TOCTOU bugs.
(cherry picked from commit 36ea70c0993cb48d3155c2de6d6c8e48a2b08c60)
(cherry picked from commit aac5b80fca)
During stage2 (prepare) of an activation, check if the connection is
private and if it contains any certificate/key path. If so, start
reading the files and delay stage2. Once done, store the files'
content into priv->private_files.table and continue the activation.
(cherry picked from commit 98e6dbdf21e5b165bae498ab2a29bb14f331ccd1)
(cherry picked from commit a417df3484)
Add function nm_utils_read_private_files(). It can be used to read a
list of paths as the given user. It spawns the daemon-helper to read
each path and returns asynchronously a hash table containing the files
content.
Also add nm_utils_get_connection_private_files_paths() to return a
list of file paths referenced in a connection. The function currently
returns only 802.1x file paths for certificates and keys.
(cherry picked from commit de4eb64253d493364d676b509f63f2e8d1810061)
(cherry picked from commit 9432822f34)
Rename uid to to blob_id, and con_uid to con_uuid.
(cherry picked from commit 586f7700b8ad6b4b4cffdb4cdb2bed2e4726ef5c)
(cherry picked from commit a17f51fe15)
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 1d90d50fc6e8c167581c6831c2511bc4148f234b)
(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 0093bbd9507df3b16eaa08cd3a6b799b678c7599)
(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 285457a5f8284f21387753d7f245e3f51ce29248)
(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 3d76d12eee88b667d1a385b861c54fcdd4e490ed)
(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 59543620dcf7bb3e4b1316536f0330ab4a752e3e)
(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)
