We should prefer the cleanup macors nm_auto*() because they express
ownership in code.
Also, they allow to return early without additional cleanup code.
That way we can refactor if-else blocks.
Also, in cases where we intentionally pass on the reference, we use
g_steal_pointer(), which literally spells out what happens in code.
If we find a matching connection, ensure it's exactly as we want it
before actually proceeding to activate it. Fixes this problem:
# nmcli dev wifi connect "Network of Doom" password santa <-- bad
Error: Connection activation failed: (7) Invalid secrets
# nmcli dev wifi connect "Network of Doom" password satan <-- correct
Error: Connection activation failed: (7) Invalid secrets
The password is now correct, but nmcli chose to re-activate the wrong
connection it created previously.
Do not check for password when creating a simple connection object for
"nmcli dev wifi connect".
This makes no difference in practice. The password is checked for
existence later on and the connection instance is created anyway. This
just makes things look a bit more consistent.
Instead of straight-out rejecting extra parameters for various nmcli
sub-commands (such as "nmcli dev status", "nmcli dev wifi rescan" or
"nmcli dev wifi connect", etc.), we just print a warning and go ahead.
This is unhelpful. In case the user makes a typo, we'll do the wrong
thing and possibly even drown the warning in the output.
While at that, let's make the error message consistent. One less string
to translate.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/217
Make use of the new API. Note that AddConnection2() covers all
functionality of AddConnection() and AddConnectionUnsaved(). Let's
only use one API for all.
There is a minor downside to this patch: now nmcli requires
libnm 1.20 API. Note that libnm's nm_client_add_connection2()
makes an effort to avoid AddConnection2() under the hood to
still work against older server versions. So, you can use nmcli
with libnm 1.20 to talk to older versions of NetworkManager.
But with this change nmcli strictly requires libnm 1.20. I think that is
sensible because commonly nmcli requires a libnm version that is as new
as itself.
Also, the value of allowing nmcli to talk to older NetworkManager
versions is during package upgrade (where the daemon might not be
restarted). This is much less concern w.r.t. to updating the nmcli/libnm
combo, which is commonly packaged together.
The 'bt-type' property alias accepts values provided by
gen_func_bt_type(); instead the 'bluetooth.type' property can only be
set to [dun, panu, nap] and therefore it doesn't need special
handling.
The only remaining GValue transform function was from GHashTable (of (str,str) type)
to string. Drop that too, and implement the conversion in _get_fcn_gobject_impl().
Note that there are few GObject properties of type GHashTable and most
of them implement their own logic. This only applies to
"802-3-ethernet.s390-options".
Also, always sort the keys. Otherwise, the output is not stable.
The g_value_register_transform_func() for handling GBytes was not actually used.
All properties of type G_TYPE_BYTES have their explit handler how to convert bytes
to string. That is good, because the implementation there was very bad (it did not
honor pretty/parsable get-type).
Also, merge _get_fcn_gobject_bytes() into _get_fcn_gobject_impl(). We
already have a generic handler that handles properties solely based on
the GObject type: _get_fcn_gobject_impl(). Just let it also handle
bytes. It's better to have fewer handlers, if they don't need special
context.
It's ugly to modify the global behavior of glib to convert between
types. Instead, _get_fcn_gobject_impl() is perfectly capable to implement
converting a strv array to string.
"libnm-core" implements common functionality for "NetworkManager" and
"libnm".
Note that clients like "nmcli" cannot access the internal API provided
by "libnm-core". So, if nmcli wants to do something that is also done by
"libnm-core", , "libnm", or "NetworkManager", the code would have to be
duplicated.
Instead, such code can be in "libnm-libnm-core-{intern|aux}.la".
Note that:
0) "libnm-libnm-core-intern.la" is used by libnm-core itsself.
On the other hand, "libnm-libnm-core-aux.la" is not used by
libnm-core, but provides utilities on top of it.
1) they both extend "libnm-core" with utlities that are not public
API of libnm itself. Maybe part of the code should one day become
public API of libnm. On the other hand, this is code for which
we may not want to commit to a stable interface or which we
don't want to provide as part of the API.
2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core"
and thus directly available to "libnm" and "NetworkManager".
On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm"
and "NetworkManager".
Both libraries may be statically linked by libnm clients (like
nmcli).
3) it must only use glib, libnm-glib-aux.la, and the public API
of libnm-core.
This is important: it must not use "libnm-core/nm-core-internal.h"
nor "libnm-core/nm-utils-private.h" so the static library is usable
by nmcli which couldn't access these.
Note that "shared/nm-meta-setting.c" is an entirely different case,
because it behaves differently depending on whether linking against
"libnm-core" or the client programs. As such, this file must be compiled
twice.
Scripts should refer to connections by UUID. That means, whenever a
UUID matches, that is really what the user wants. The specifier "uuid"
must have precedence over "id" (and all others). That means, we must
search all connections.
For example:
$ UUIDS=($(nmcli -g TYPE,UUID connection show | sed -n 's/802-11-wireless://p'))
$ nmcli -f connection.id,connection.uuid connection show "${UUIDS[@]}"
in this case we must preferrably match by UUID, regardless of whether
a "connection.id" exists.
Note that if you have:
$ nmcli connection show | grep fdf7b2d2-2858-3938-9b14-7f1b514a9a00
b fdf7b2d2-2858-3938-9b14-7f1b514a9a00 ethernet --
fdf7b2d2-2858-3938-9b14-7f1b514a9a00 ab9f3891-3420-335e-89da-f14c1b94c540 ethernet --
then certain commands will still select all matching connections:
$ nmcli -f connection.id,connection.uuid --mode multiline connection show fdf7b2d2-2858-3938-9b14-7f1b514a9a00
connection.id: fdf7b2d2-2858-3938-9b14-7f1b514a9a00
connection.uuid: ab9f3891-3420-335e-89da-f14c1b94c540
connection.id: b
connection.uuid: fdf7b2d2-2858-3938-9b14-7f1b514a9a00
This only makes a difference for commands that must pick only one profile:
$ nmcli connection modify fdf7b2d2-2858-3938-9b14-7f1b514a9a00 con-name new-name
Since commit 62b939de4e ('cli: add nmc_complete_strv() which takes a
string array for completion that may contain NULL'), the sentinel is
no longer needed.
When nmcli needs secrets for a connection it asks them for every known
setting. nmtui is a bit smarter and asks them only for settings that
actually exist in the connection. Make a step further and let clients
ask secrets only for setting that exist *and* have any secret
property. This decreases the number of D-Bus calls when editing or
showing a connection with secrets.
https://bugzilla.redhat.com/show_bug.cgi?id=1506536https://github.com/NetworkManager/NetworkManager/pull/327
Call the correct _finish() function for
nm_client_add_and_activate_connection_async(). add_and_activate_cb()
somewhat confusingly alternates between two different ones depending on
whether info->create is set.
Fixes: 3593237527 ('cli: reuse connections in nmcli dev wifi con')
https://github.com/NetworkManager/NetworkManager/pull/326
I find it questionable, how nmcli likes to coerce the empty input to
NULL to indicate resetting the value. If nmcli would like to set a
default, it should use a different way of signalling that. Anyway, the
assertion was too strict.
$ nmcli connection modify "$PROFILE" +ipv4.addresses ''
Setting one property might affect multiple properties.
For example, setting a team property might also emit property changed
signal for "team.config".
Or, one property might be modified multiple times. For example list
properties may first clear the property, then append multiple elements.
Or a list property might remove multiple elements.
Combine these signals via g_object_freeze_notify() and
g_object_thaw_notify().
set_fcn() and remove_fcn() are strongly related. They should accept
arguments in the same format, hence the parsing of the arguments should
be done at one place.
In fact, previously the parsing was separate, leading to ugly
inconsistencies:
$ nmcli connection modify "$PROFILE" +vpn.data x=y
$ nmcli connection modify "$PROFILE" -vpn.data x=y
Error: failed to remove a value from vpn.data: invalid option 'x=y'.
or
$ nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.1.5/24,192.168.2.5/24
$ nmcli connection modify "$PROFILE" -ipv4.addresses 192.168.1.5/24,192.168.2.5/24
Error: failed to remove a value from ipv4.addresses: invalid prefix '24,192.168.2.5/24'; <1-32> allowed.
Let set_fcn() handle set-default, set-all, add, and subtract.
Previously, set_fcn() could only append values. Now, pass on the modifier
so that it may append, set all, or reset the default.
These operations are strongly related and should be handled by the same
set_fcn() function.
The property implementation must itself decide how to reset a value.
We must not rely on properties being plain GObject properties.
Let set_fcn() accept %NULL value to indicate resetting the default.
It's fundamentally wrong to have separate "remove_fcn" and "set_fcn"
implementations. Set, reset, add, and remove are all similar, and should
be implemented in a similar manner.
Merge the implementations all in set-property, which now can:
- reset the value (value == NULL && modifier == '\0')
- set a value (value != NULL && modifier == '\0')
- add a value (value != NULL && modifier == '+')
- remove a value (value != NULL && modifier == '-')
The real problem is that remove_fcn() behaves fundamentally different
from set_fcn(). You can do "+setting.property value1,value2" but you
cannot remove them the same way. That is because most remove_fcn()
implementations don't expect a list of values. But it's also because of
the unnatural split between set_fcn() and remove_fcn().
The next commit will merge set_fcn(), remove_fcn() and reset property.
This commit just merges them all in nmc_setting_set_property().
ipv4_method_changed_cb() and ipv6_method_changed_cb() are horrible hacks, as they
use a static variable to cache the previous value.
Anyway, don't fix that now.
We are going to drop nmc_property_get_gvalue()/nmc_property_set_gvalue()
because that works only with GObject based properties -- and having this
API around wrongly suggests it works in general. Use the native types
directly.
"reset" is just a special case of "set". We can keep nmc_setting_reset_property() as a convenience
function, but it must be implemented based on nmc_setting_set_property().
Also, reset only used nmc_property_set_default_value(), which only works
with GObject based properties. It's wrong to assume that all properties
are GObject based. By implementing it based via nmc_setting_set_property()
we can fix this (later).
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.
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)
If we already specified "type" or "file", don't offer it for
completion again.
$ nmcli connection import type openvpn <TAB>
file type
(cherry picked from commit fea0f4a5ea)
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).
Previously, Wi-Fi scans uses polkit action
"org.freedesktop.NetworkManager.network-control". This is introduced
in commit 5e3e19d0. But in a system with restrict polkit rules, for
example "org.freedesktop.NetworkManager.network-control" was set as
auth_admin. When you open the network panel of GNOME Control Center, a
polkit dialog will keep showing up asking for admin password, as GNOME
Control Center scans the Wi-Fi list every 15 seconds.
Fix that by adding a new polkit action
"org.freedesktop.NetworkManager.wifi.scan" so that distributions can
add specific rule to allow Wi-Fi scans.
[thaller@redhat.com: fix macro in "shared/nm-common-macros.h"]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/68
