When a failure occurs on deactivation of a connection, no error was
shown on the TUI client. It was not obvious if anything was actually
happening after pressing the <Deactivate> button.
This patch shows the error in a dialog just like we do when a failure
occurs on activation of a connection.
https://mail.gnome.org/archives/networkmanager-list/2020-May/msg00004.html
Rework parsing of nmcli's passwd-file.
1) support backslash escaping of secrets.
- only the secret can be backslash escaped, the property and setting
name cannot.
This is a change in behavior for passwd-files with secrets that contain
a backslash.
2) strip the white space around the secret. This is a change in behavior
for secrets that had leading or trailing spaces. Note that you can
backslash escape spaces in secrets.
3) strip white space around the setting.property key. This is also a
change in behavior, but such keys would never have been valid
previously (or the caller would have performed the same kind of
stripping).
4) accept '=' as alternative delimiter beside ':'. The ':' feels really
odd and unexpected. Also accept '='. This is a change in behavior if
keys would contain '=', which they really shouldn't.
5) reject non-UTF-8 secrets and keys. For keys, that is not an issue,
because such keys were never valid. For secrets, it probably didn't
work anyway to specify non-UTF-8 secrets, because most (if not all)
secrets are transmitted via D-Bus as strings where arbitrary binary
is not allowed.
6) ignore empty lines and lines starting with '#'.
7) ensure we don't leak any secrets in memory.
1) to 4) are changes in behavior. 3) and 4) seem less severe, as they
only concern unusual setting.property keys, which really shouldn't be
used (although, VPN secrets can have almost arbitrary names *sigh*).
1) and 2) is more dangerous, as it changes behavior for secrets that
contain backslashes or leading/trailing white space.
Callbacks might reference the main loop when destroying the NMClient
instance. Unref the main loop later.
# G_DEBUG=fatal-warnings valgrind --num-callers=100 nmcli device wifi connect home
^C
Error: nmcli terminated by signal Interrupt (2)
Error: Connection activation failed: (0) No reason given.
==11050== Invalid read of size 4
==11050== at 0x4C90D3D: g_main_loop_quit (in /usr/lib64/libglib-2.0.so.0.6200.6)
==11050== by 0x431435: quit (devices.c:934)
==11050== by 0x43272C: connected_state_cb (devices.c:1919)
==11050== by 0x4BF6741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x4C0A603: ??? (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x4C133AD: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x4C139D2: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x4BFB1C3: ??? (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x4BFAAEC: ??? (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x4BFD86A: g_object_thaw_notify (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x48BA040: _nm_client_notify_event_emit (nm-client.c:937)
==11050== by 0x48CA01F: _dbus_handle_changes_commit (nm-client.c:2850)
==11050== by 0x48CC221: _dbus_handle_changes (nm-client.c:2864)
==11050== by 0x48CC833: _init_release_all (nm-client.c:6969)
==11050== by 0x48D2818: dispose (nm-client.c:7826)
==11050== by 0x4BFBC27: g_object_unref (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x43FF93: nmc_cleanup (nmcli.c:941)
==11050== by 0x4410AD: main (nmcli.c:1005)
==11050== Address 0x54738fc is 12 bytes inside a block of size 16 free'd
==11050== at 0x4839A0C: free (vg_replace_malloc.c:540)
==11050== by 0x4C9649C: g_free (in /usr/lib64/libglib-2.0.so.0.6200.6)
==11050== by 0x4410A3: main (nmcli.c:1004)
==11050== Block was alloc'd at
==11050== at 0x483AB1A: calloc (vg_replace_malloc.c:762)
==11050== by 0x4C96400: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6200.6)
==11050== by 0x4C90A45: g_main_loop_new (in /usr/lib64/libglib-2.0.so.0.6200.6)
==11050== by 0x441020: main (nmcli.c:987)
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/501
lgtm.com flags this as "Empty block without comment".
Avoid it.
This code is of course ugly. Much work was already done to
port such occurrences, and more is needed. I won't add a FIXME
comment, because lgtm.com flags those too. :)
Static analysis tools flag the use of localtime() because it is not
thread safe. Of course, that was no problem here, but avoiding the
warning is simple.
Also, if we allocate 128 bytes, let strftime use it.
Reported by coverity:
>>> CID 210213 Uninitialized pointer read (UNINIT)
>>> Using uninitialized value iter when calling
_nm_auto_free_variant_iter
Fixes: df1d214b2e ('clients: polkit-agent: implement polkit agent without using libpolkit')
Reported by coverity:
>>> CID 210217: (UNINIT)
>>> Using uninitialized value "identities_gvariant" when calling
"gs_local_variant_unref".
Fixes: df1d214b2e ('clients: polkit-agent: implement polkit agent without using libpolkit')
Add a new "driver" match option to nm-settings. It allows to disable a
network connection configuration if a pattern is found or is not found
in the device driver name.
Add a new "kernel-command-line" match option to nm-settings. It allows
to disable a network connection configuration if a pattern is found or
is not found in /proc/cmdline.
"connection.mud-url" is a commonly not used parameter, that most
users won't care. To minimize the output of
$ nmcli connection show "$PROFILE"
hide the MUD URL if it is unset.
This mechanism of nmcli is not yet great, because there is currently
no way to print a default value, and
$ nmcli -f connection.mud-url connection show "$PROFILE"
does not work as one would expect(??). But that is a shortcoming of the
general mechanism in nmcli, and not specific to the MUD URL property.
Conceptionally, the MUD URL really depends on the device, and not so
much the connection profile. That is, when you have a specific IoT
device, then this device probably should use the same MUD URL for all
profiles (at least by default).
We already have a mechanism for that: global connection defaults. Use
that. This allows a vendor drop pre-install a file
"/usr/lib/NetworkManager/conf.d/10-mud-url.conf" with
[connection-10-mud-url]
connection.mud-url=https://example.com
Note that we introduce the special "connection.mud-url" value "none", to
indicate not to use a MUD URL (but also not to consult the global connection
default).
The default value of a string property (almost?) always should be
%NULL, which means the value is absent and not specified.
That is necessary because adding new properties must be backward
compatible. That means, after upgrade those properties will have their
value unset. In these cases, %NULL really translates to some property
dependant behavior (like not using the value, or using a special default
value).
For example leaving "ethernet.cloned-mac-address" unset really means
"preserve", with the twist that %NULL can be overridden by a global
connection default.
For most string properties, a value can only be unset (%NULL) or set to
a non-empty string. nm_connection_verify() enforces that.
However, for some properties, it makes sense to allow both unset and the
empty word "" as value. This is the case if a property can have it's
value overridden by a global connection default, or if we need the
differentiation between having a value unset and having it set to the empty
word.
We would usually avoid allowing the empty word beside %NULL, because
that makes it hard to express the difference on the command line of
nmcli or in a UI text entry field. In the "ethernet.cloned-mac-address"
example, "" is not necessary nor sensible.
However, for some properties really all string values may be possible (including
"") and also unset/%NULL. Then, we need some form of escaping/mangling,
to allow to express all possible values. The chosen style here is that
on nmcli input field "" means %NULL, while a word with all white space
stands for the word with one less white space characters.
This is still unused, but I think it makes sense for some properties.
I initially added this for "connection.mud-url", but a valid MUD-URL
always must start with "https://", so not all strings are possible
to begin with. So to explicitly express that no MUD-URL should be set,
we will instead introduce a special word "none", and not use the empty
word, due to the oddities discussed here. However, I think this may
well make sense for some properties where all strings are valid.
NetworkManager will reject scan requests, if it is currently scanning.
That is very wrong. Even if NetworkManager wants to ratelimit scan
requests or not scan at critical moments, it should never reject a
request, but remember and start scanning as soon as it can.
That should be fixed.
But regardless, also nmcli can do better.
If you issue
$ nmcli device wifi list --rescan yes
once, it works as expected.
If you issue it again right after, the scan request of nmcli will be
rejected. But nmcli cannot just merely complete and print the result.
Instead, it will wait in the hope that a scan result will be present
soon. But if the request was simply rejected, then the result will
never come, and nmcli hangs for the 15 seconds timeout.
Instead, repeatedly re-trigger scan requests, in the hope that as soon
as possible we will be ready.
Since commit c1907a218a ('libnm-core: remove gateway when
never-default=yes in NMSettingIPConfig'), the gateway gets normalized
away when the profile has never-default set.
That means,
$ nmcli connection modify "$PROFILE" ipv4.never-default yes ipv4.gateway 192.168.77.1
does not set the gateway. Likewise, if your profile has already never-default
enabled,
$ nmcli connection modify "$PROFILE" ipv4.gateway 192.168.77.1
will have no effect. That is confusing and undesirable.
Note that we don't adjust the GObject property setter for "gateway" to clear
never-default. I feel, setting one property in libnm should preferably
not unset another (there are exceptions to the rule, like for team
properties). However, for nmcli it's clear in which order properties
are set, so this change is right for the client tool.
https://bugzilla.redhat.com/show_bug.cgi?id=1785039https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/475
The profile's "ipv4.gateway" and "ipv6.gateway" has only one real
purpose: to define the next hop of a static default route.
Usually, when specifying a gateway in this way, the default route from
other addressing methods (like DHCPv4 or IPv6 autoconf) gets ignored.
If you have a WireGuard peer with "AllowedIPs=0.0.0.0/0" and
"wireguard.peer-routes" enabled, NetworkManager would automatically add
a route to the peer. Previously, if the user also set a gateway, that
route was suppressed.
That doesn't feel right. Note that configuring a gateway on a WireGuard
profile is likely to be wrong to begin with. At least, unless you take
otherwise care to avoid routing loops. If you take care, setting a
gateway may work, but it would feel clearer to instead just add an
explicit /0 manual route instead.
Also, note that usually you don't need a gateway anyway. WireGuard is a
Layer 3 (IP) tunnel, where the next hop is alway just the other side of
the tunnel. The next hop has little effect on the routes that you
configure on a WireGuard interface. What however matters is whether a
default route is present or not.
Also, an explicit gateway probably works badly with "ipv[46].ip4-auto-default-route",
because in that case the automatism should add a /0 peer-route route in a
separate routing table. The explicit gateway interferes with that too.
Nonetheless, without this patch it's not obvious why the /0 peer
route gets suppressed when a gateway is set. Don't allow for that, and
always add the peer-route.
Probably the profile's gateway setting is still wrong and causes the
profile not to work. But at least, you see all routes configured, and
it's clearer where the (wrong) default route to the gateway comes from.
