Not all implementations support having the value being an index.
For example, the implementations that are done via DEFINE_REMOVER_OPTION() macro.
The meaning of the "value" string must not be determined by
nmc_setting_remove_property_option(). It's up to the implementation
to decide whether to allow an index and how to interpret it.
$ nmcli connection add type vlan autoconnect no con-name v dev vlan.1 id 1
$ nmcli connection modify v +vlan.ingress-priority-map 1:2,2:3
$ nmcli connection modify v +vlan.ingress-priority-map 2:3,4:5
$ nmcli connection modify v -vlan.ingress-priority-map 1:2,4:5
Warning: only one mapping at a time is supported; taking the first one (1:2)
Part 1, which addresses the issue for simple properties that have
a plain remove-by-value function.
Rationale:
Removing a value/index that does not exist should not be a failure.
Woule you like:
$ nmcli connection modify "$PROFILE" autoconnect no
$ nmcli connection modify "$PROFILE" autoconnect no
Error: autoconnect is already disabled
So, why would it be a good idea to fail during
$ nmcli connection modify "$PROFILE" -vpn.data ca
$ nmcli connection modify "$PROFILE" -vpn.data ca
Error: failed to remove a value from vpn.data: invalid option 'ca'.
Generally, it should not be an error to remove an option, as long
as the option itself is valid. For example,
$ nmcli connection modify "$PROFILE" -vlan.ingress-priority-map bogus
should fail, but
$ nmcli connection modify "$PROFILE" -vlan.ingress-priority-map 1:5
should succeed even if there was nothing to remove.
The "from" part is like a key for the egress/ingress priority map.
Extend nm_setting_vlan_remove_priority_str_by_value() to accept only the
"from" part when finding and deleting value. This allows for:
$ nmcli connection modify "$PROFILE" -vlan.ingress-priority-map '4:'
$ nmcli connection modify "$PROFILE" -vlan.ingress-priority-map '4:*'
to fuzzy match the value to remove.
How hard can it be to use strtol()? Apparently very. You need to check
errno, the endpointer, and also not pass in an empty string.
Previously, nmc_string_to_uint_base() would silently accept "" as valid
number. That's a bug.
Btw, let's not use strtol() (or nmc_string_to_uint*()). We have
_nm_utils_ascii_str_to_int64(), which gets all of this right.
We have code in "shared/nm-utils" which are general purpose
helpers, independent of "libnm", "libnm-core", "clients" and "src".
We have shared code like "shared/nm-ethtool-utils.h" and
"shared/nm-meta-setting.h", which is statically linked, shared
code that contains libnm related helpers. But these helpers already
have a specific use (e.g. they are related to ethtool or NMSetting
metadata).
Add a general purpose helper that:
- depends (and extends) libnm-core
- contains unrelated helpers
- can be shared (meaning it will be statically linked).
- this code can be used by any library user of "libnm.so"
(nmcli, nm-applet) and by "libnm-core" itself. Thus, "src/"
and "libnm/" may also use this code indirectly, via "libnm-core/".
Support importing ".conf" files as `wg-quick up` supports it.
`wg-quick` parses several options under "[Interface]" and
passes the remainder to `wg setconf`.
The PreUp/PreDown/PostUp/PostDown options are of course not supported.
"Table" for the moment behaves different.
(cherry picked from commit a3a8583c31)
@secrets is unreferenced at the end of request_secrets_from_ui() and
so try_spawn_vpn_auth_helper() must take a reference to it.
Fixes: 1a0fc8d437
(cherry picked from commit b57a3a4cc6)
Rework the explicit implementation of NM_SETTING_802_1X_PASSWORD_RAW
handling to generically handle GBytes properties.
Note that the NM_SETTING_802_1X_PASSWORD_RAW setter accepts a legacy
format where hex-words are separated by space. I don't think we want
to support this format for new options.
So, there are two possibilities:
1) either leave _set_fcn_802_1x_password_raw() as-is, with the special
handling.
2) interpret a property-data gobject_bytes.legacy_format.
1) seems to make more sense, because there is only one such property,
and we won't use this for new properties. However let's do 2), because
it shows nicely the two styles side-by-side. In other words, let's
password-raw also be a _pt_gobject_bytes typed property, with some
special legacy handling. Instead, of having it an entirely separate
property type (with a different setter implementation). I think it's
better to have the parts where they differ pushed down (the "stack") as
much as possible.
- it's less lines of code (for the caller).
- it's a function that can be easier unit-tested on its own.
Possibly there are already other unit-tests that cover it.
- it's more efficient than the GString based implementation.
- it reuses our one and only bin-to-hexstr implementation.
For now only add the core settings, no peers' data.
To support peers and the allowed-ips of the peers is more complicated
and will be done later. It's more complicated because these are nested
lists (allowed-ips) inside a list (peers). That is quite unusual and to
conveniently support that in D-Bus API, in keyfile format, in libnm,
and nmcli, is a effort.
Also, it's further complicated by the fact that each peer has a secret (the
preshared-key). Thus we probably need secret flags for each peer, which
is a novelty as well (until now we require a fixed set of secrets per
profile that is well known).
When asking for the preshared-key for WireGuard peers, the secret request
will be very verbose with redundant information. Allow suppressing the entry
id from the prompt.
It's not really used, but we shouldn't just forget about it.
Currently, we fill requests only based on the connection-type, ignoring
the setting-name. I guess, the concept of requesting secrets for a setting
is utterly broken. But equally broken it is to just look at the connection
(type). At least, don't just throw parts of the request away but keep
it.
Currently, default-routes cannot be added like regular static-routes
as ipv4.routes setting.
Instead, one has to configure "ipv4.gateway" and "ipv4.never-default".
That of course should be fixed, for example to configure a default-route
in different routing tables.
As it is, both nmcli's parse function and libnm's
NMSettingIPConfig:verify() functions reject default-routes.
But nmcli goes way beyond that, it also rejects all networks with
"0.0.0.0"/"::" even if their prefix length is not zero. Such routes are
not default-routes, and nmcli has no business rejecting them. The
correct way for checking for a default-route is to check the prefix-length
for zero.
Drop the wrong validation in nmcli.
Note, it may still not be the best idea to add catch-all routes like
"0.0.0.0/1" and "128.0.0.0/1". It just defeats what counts as a default-route.
NM has other means (like configuring the route-metric) to handle routing
in face of multiple interfaces. But sure, whatever works for you.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/114https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/75
This adds support for configuring the Wi-Fi connections to use SAE. SAE
is a password-based authentication mechanism that replaces WPA-PSK in
WPA3-Personal.
The pass phrase is still stored in the "psk" property, with some
limitations lifted.
The generic connection validation produces a good result:
Error: failed to modify 802-11-wireless-security.psk: ':(' is not a valid PSK.
vs.:
Error: Failed to add 'wifi666' connection: 802-11-wireless-security.psk: property is invalid
Like also done for autotools, create and use intermediate libraries
from "shared/nm-utils/".
Also, replace "shared_dep" by "shared_nm_utils_base_dep". We don't
need super fine-grained selection of what we link. We can always
link in "shared/libnm-utils-base.a", and let the linker throw away
unsed parts.
The callback must be invoked, as also documented.
Otherwise, the tracked info gets leaked.
Let NMSecretAgentOld (the caller) be a bit resilient against
bugs in the client, and avoid a crash by prematurely remove
the request-info from the pending list. That does not fully
workaround the bug (it leads to a leak), but at least it does
not cause other "severe" issues.
The leak was present earlier as well.
NMSecretAgentOld's get_secrets_cb() gets this right and takes
a floating reference. So this was correct.
However, make this a bit more robust, and don't pass on
floating references. This was, we don't require the callee
to consume the reference.
