The Station.ConnectHiddenNetwork will provision a network in the iwd
known-networks list. This should allow us to later use the
Network.Connect interface to connect in the future.
(Note: Attempts to use Station.ConnectHiddenNetwork on already provisioned
networks, i.e. networks iwd knows about, will fail.)
This commit squashed several fixups made by thaller.
Newer versions of iwd has supported connecting to hidden networks for a
while now. There's a separate "connect-hidden" command in iwctl that
needs to be used instead of the regular "connect" command.
The equivalent on dbus is to use ConnectHiddenNetwork instead of
Connect on the Station interface. NetworkManager however uses the
Network interface and given we the explicit SSID usage we can connect
to hidden networks with that.
This change disabled the explicit check that disallows even attempting
hidden networks when using iwd.
This has been tested to work with a previously known hidden network.
Tests connecting to a previously unknown network has failed.
GObject signals only complicate the code and are less efficient.
Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous
request. Of course, fundamentally emitting a signal *is* the same as
calling a method. However, implementing this as signal is really not
nice nor best practice. For one, there is a (negligible) overhead emitting
a GObject signal. But what is worse, GObject signals are not as strongly
typed and make it harder to understand what happens.
The signal had the appearance of providing some special decoupling of
NMDevice and NMManager. Of course, in practice, they were not more
decoupled (both forms are the same in nature), but it was harder to
understand how they work together.
Add and call a method nm_manager_device_auth_request() instead. This
has the notion of invoking an asynchronous method. Also, never invoke
the callback synchronously and provide a cancellable. Like every asynchronous
operation, it *must* be cancellable, and callers should make sure to
provide a mechanism to abort.
It's about as complicated to track a CList as it is to track
an allocated array. The latter requires fewer allocations and
has better locality. That makes it preferable.
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.
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).
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.
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.
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.
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.
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.
We shall emit a changed signal when PolicyKit changes. That implies also
emitting the signal when PolicyKit starts. Watch the name owner for
that.
Note that I don't manage to actually receive the "Changed" signal from
PolicyKit. That seems to be due to wrong D-Bus configuration which
prevents the "Changed" signal from PolicyKit to reach NetworkManager.
That is independent from this patch.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/469
Fix the following error when invoking the Connect() p2p method:
call-p2p-connect: failed with Method “fi.w1.wpa_supplicant1.Interface.P2PDevice.Connect” returned type “(s)”, but expected “()”
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling')
- indent by 4 spaces, not 8. We do that for the other 2 D-Bus
configuration files. Also, since our lines here are rather long,
save a bit in this regard.
- don't wrap lines for the XML elements. It makes it easier to visually
parse.
- sort some lines asciibetically.
No changes otherwise.
When the server is restarted the write to unix socket fails with
EPIPE. In such case, don't fail all the calls in queue; instead, after
a sync of the ovsdb state (through a monitor call), start processing
the queue again, including the call that previously failed.
Add a retry counter to avoid that calls are stuck in the queue forever
in a hypothetical scenario in which the write always fails.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/459
