We want that our asynchronous operations are cancellable.
In fact, NMAuthChain is already (manually) cancellable by the
user calling nm_auth_chain_destroy(). However, sometimes we have a
GCancellable at hand, so the callers would have to register to the
cancellable themselves.
Instead, support setting a cancellable to the NMAuthChain, that aborts
the request and invokes the callback.
It does so always on an idle handler. Also, the user may only set the
cancellable once, and only before starting the first call.
NMDevice already has access to the NMSettings singleton. It is permissible that
NMDevice *knows* about NMManager. The current alternative is emitting GObject signals
like NM_DEVICE_AUTH_REQUEST, pretending that NMDevice and NMManager would be completely
independent, or that there could be anybody else handling the request aside NMManager.
No, NMManager and NMDevice may know each other and refer to each other. Just like
NMDevice also knows and refers to NMSettings.
When handling a GCancellable, you make decisions based on when the cancelled
property of a GCancellable changes. Correctly handling a cancellable becoming
uncancelled again is really complicated, nor is it clear what it even means:
should the flipping be treated as cancellation or not? Probably if the
cancelled property gets reset, you already start aborting and there is
no way back. So, you would want that a cancellation is always handled.
But it's hard to implement that correctly, and it's odd to claim
something was cancelled, if g_cancellable_is_cancelled() doesn't agree
(anymore).
Avoid such problems by preventing users to call g_cancellable_reset().
"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.
If a device only has an IPv6 link-local address, we don't generate an
assumed connection. Therefore, when a new slave connection (without IP
configuration) is activated on the device, we don't deactivate any
existing connection and the link-local address remains configured.
The IP configuration of an activated slave should be predictable and
not depend on the previous state; let's flush addresses and routes on
activation.
https://bugzilla.redhat.com/show_bug.cgi?id=1816517https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/480
I find it simpler to follow the pattern of checking conditions and
"erroring out", by going to the next entry. The entire loop already
behaves like that.
env -i starts with an empty environment, which is undesired when the build
environment needs certain environment variables to function.
One such example is a custom PYTHONPATH, which gets dropped by env -i and
results in the nm-settings-docs.xml generator not finding the gi Python module.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/478
While we request a scan, we are not yet actually scanning. That means, the supplicant's
"scanning" property will only change to TRUE a while after we initiate the scan. It may
even never happen.
We thus need to handle that the request is currently pending and react when the
request completes.
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.
Add nm_utils_invoke_on_timeout() beside nm_utils_invoke_on_idle().
They are fundamentally similar, except one schedules an idle handler
and the other a timeout.
Also, use the current g_main_context_get_thread_default() as context
instead of the singleton instance. That is a change in behavior, but
the only caller of nm_utils_invoke_on_idle() is the daemon, which
doesn't use different main contexts. Anyway, to avoid anybody being
tripped up by this also change the order of arguments. It anyway
seems nicer to first pass the cancellable, and the callback and user
data as last arguments. It's more in line with glib's asynchronous
methods.
Also, in the unlikely case that the cancellable is already cancelled
from the start, always schedule an idle action to complete fast.
For one, the setters sd_dhcp_client_set_mud_url() and sd_dhcp6_client_set_request_mud_url()
assert that the value honors these settings. So, we must never pass such values to the
function. Also, before calling n_dhcp4_client_probe_config_append_option()
the code doesn't check whether the URL is short enough. That would be
a bug (unless we ensure that the property is valid from the beginning).
In general, it is necessary to strictly validate the parameter.
Also, returning NM_SETTING_VERIFY_NORMALIZABLE_ERROR for a property that does
not get normalized is a bug.
The comment isn't right. The fixed array size is in the header file,
because other parts of the code need to know how many elements are in
the array. The alternative would be a define for the size, but that
is only redundant information. Also, even with a define the user who
adds an entry needs to adjust the code in the header. Explicitly stating
the array size in the header makes it almost impossible to accidentally
choosing the wrong size, because the compiler (and unit tests) ensure
the consistency.
We have this as a GObject property, so that it can be set at construct
time (to be never modified afterwards). We don't need a readable
GObject property, because there is a getter function that should be
used instead.
- avoid g_assert(). Either we want to gracefully assert (g_return_*()) or we
want to use assertions that are disabled in production builds (nm_assert());
- rename variable s_connection to s_con. This is how variables for this
purpose are commonly called.
Commit b2a0738765 ('man: improve manual page for nm-online') removed
the explanation of how may-fail can be used to wait for a specific
address family during boot. I found that part useful. Add it again,
adapting it to the new behavior introduced by 1e5206414a ('device:
don't delay startup complete for pending-actions "autoconf", "dhcp4"
and "dhcp6"').
https://bugzilla.redhat.com/show_bug.cgi?id=1825666
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.
This will be useful to set future options on the NMIPConfig.
Yes, the code duplication of NMIP[46]Config is horrible. Needs
to be unified in the future.
