set_current_ap() would always call schedule_periodic_scan() but: first it
would do nothing when current_ap was non-NULL because we
schedule_periodic_scan makes sure not to auto-scan when connected.
Secondly state_changed() already calls schedule_periodic_scan
indirectly through set_can_scan() so normally when we disconnect and
current_ap becomes NULL we already do trigger a scan. The only
situation where we didn't is when a connection is cancelled during
NEED_AUTH because IWD's state doesn't change, so we add a
schedule_periodic_scan() call in network_connect_cb() on error.
Rename NMDeviceIwdPrivate.can_connect to .nm_autoconnect in preparation
to also add .iwd_autoconnect.
Rename misnamed local variable iwd_connection to nm_connection, we'll
need a new iwd_connection variable later.
In this state, same as in DISCONNECTED or ACTIVATED, allow scanning if
IWD is in the "connected" or "disconnected" states as there's no reason
not to scan.
Implement a Cancel method on our IWD secrets agent DBus object. This
results in a call to nm_device_iwd_agent_query() for the device
currently handling the request and the @invocation parameter is NULL to
signal that the current query is being cancelled.
nm_device_iwd_agent_query doesn't do much with this call just yet but
the handling will be necessary when IWD autoconnect is used by NM.
The type information of NMObject is entirely static. And there
are certain conditions how this information should be. Add some
more checks.
We need priv_ptr_offset set if (and only if) we also have
property_ao_info or property_o_info registered.
This patch is replacing NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_LOW
with NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_10 and
NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_HIGH with
NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_30. In addition it is
introducing NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_20 which is a
middle point between the existing priorities.
This new priority is needed due to Veth support incoming. It will be
used to prevent the creation a NMDeviceWired instance.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
[thaller@redhat.com: split original patch]
We will need more levels of priority. Change the naming
to make room for that.
sed 's/NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_LOW/NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_10/g' `git grep -l NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_ ` -i
sed 's/NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_LOW/NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_10/g' `git grep -l NML_DBUS_META_INTERFACE_PRIO_INSTANTIATE_ ` -i
./contrib/scripts/nm-code-format-container.sh
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
[thaller@redhat.com: split original patch]
The if-else-if constuct spans many lines and it is not easy to see that
there is no common action after the if-else-if construct.
Instead, at the end of each if-block, just "continue" the loop. This
is similar to a "return-early" apprach and it mean you don't need
to think what happens at the end of the if-block.
Removing a setting that is not present should not be an error. The user
asked that the profile doesn't have the requested setting, and that
should succeed (even if that results in no actual change).
Consider when you want to make a hotspot profile "open". That implies
to remove the "wifi-sec" and "802-1x" settings. But you may
not check before whether the profile is already open, and whether
it already has those settings. We should just allow
$ nmcli connection modify "$PROFILE" remove wifi-sec remove 802-1x
to succeed, regardless whether this changes anything or not.
Likewise, if you do
$ nmcli connection modify "$PROFILE" con-name foo
$ nmcli connection modify "$PROFILE" con-name foo
then the second command doesn't fail with "the name is
already \"foo\"". It just succeeds.
nmcli --complete-args connection add type ''
would not show "ovs-{dpdk,patch}", because the conditions about what
makes a base type are not consistent with what NMSettingConnection's
verify() does.
Fix that.
Currently the cancellable is not yet used. Drop it again.
However, I think the code might be useful, so I hope to revert
this commit afterwards to use it.
Also support reapply. During reapply we try to preserve
keys that are added externally.
However, the current implementation does not properly use transactions
to ensure there is no race here.
We don't need every log line repeat all the parameters
of the call. Each call should have a unique identifier
(which is NM_HASH_OBFUSCATE_PTR(call)) and only the first
message from a call contains all the details.
API should fail with a "cancelled" error if (and only if)
the user cancelled the operation. An error to communicate
with OVSDB or being disconnected should fail with a different
reason.
GArray is nice, because it is more memory efficient and encourages
local access. However, growing the array also means that all entries
get relocated, that means, we cannot pass on a pointer to a call
instance.
Next, we will add a way to cancel operations via a GCancellable.
That means, we subscribe to the cancelled signal and need to pass
on a user-data that indicates which call got cancelled. Since with
an GArray the calls can be relocated, we would anyway need an
additional allocation (just for the user data). So, we wouldn't
actually safe anything but make the code more complicated.
As often, CList works great in this use case. Use it.
It's in general nicer to have all definitions of structs and enums
a the top of the source file. As enums and structs are commonly used
by functions, it's often nice to have the enums and structs defined
first, before all functions.
The python example is (also) used to test the feature. That is because
currently nmcli does not yet have support for ovs.external-ids and this
API is only accessible via D-Bus (or a tool like this example).
External connections are devices that are configured outside of
NetworkManager. Such devices should be mostly ignored and not
be interfered with.
Note that we tend to create external connection profiles for
such devices. That happens for example if you use wg-quick to
manage a WireGuard interface outside of NetworkManager. But it
really happens for any interface.
This generated profile has no DNS configuration. Unless we use
the systemd-resolved backend, they thus don't contribute to the DNS
settings (which is fine).
However, with systemd-resolved, NetworkManager would also reset
the DNS configuration of those external interfaces. That is clearly
wrong. NetworkManager should only care about the interfaces that it
actively manages and leave others alone.
How to reproduce: use systemd-resolved and configure an interface outside
of NetworkManager. Note that `nmcli device` shows the state as
"connected (externally)". Note that `resolvectl` shows the DNS configuration
on that external interface. Do something in NetworkManager to trigger
a DNS update (e.g. SIGHUB or reactivate a profile). Note in `resolvectl`
that the external interface's DNS configuration was wiped.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/563#note_673283
Ubuntu/Debian and CentOS/Fedora are sufficiently similar that it's
better that we have only one variant of ".gitlab-ci/*-install.sh"
and "contrib/*/REQUIRED_PACKAGES".
This was already the case, however, we used to symlink
".gitlab-ci/centos-install.sh" to "fedora-install.sh". That
worked, but it didn't scale very well. For example, if we would follow
that pattern, we would also need a symlink "contrib/centos/REQUIRED_PACKAGES"
Or should "contrib/centos" symlink to "contrib/fedora"? That seems even
more wrong.
We already had the "distro.base_type" variable for that. Make use of
that also for the install script.
It's not clear that ci-fairy has a stable API. Instead, we pin the
version by specifying the git commit sha.
In the build script, install the pinned version.
ci-templates builds and caches the test containers. When the build
scripts, the ci-template or "config.yml" changes, we need to bump
the tag so that the containers get rebuild.
Partly automate this. The tag now gets generated by the template and
contains a checksum of certain build files. Thus, if you change
any build files, then `ci-fairy generate-template` would generate a
different tag. You can not miss that, because we have tests that ensure
that our ".gitlab-ci.yml" is up to date. Also, you no longer need to
manually bump the tag when a build script changes, just regenerate
".gitlab-ci.yml" with `ci-fairy generate-template`.
See also: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/merge_requests/54
> If there is no network [1] to connect to (if network interface is down [2])
> NetworkManager will make "nm-online -s" stop [3] without waiting.
[1] we usually talk about connection profiles or devices/interfaces
[2] it would be better to say, if no suitable profile is ready to
autoconnect.
[3] `nm-online -s` waits until NetworkManager declares "startup
complete" reached.
I find the wording of the comment not very clear or useful.
Possibly I don't understand it properly, but that is a problem
for a comment that is supposed to help.
Remove it.
We encountered the following situation:
* nm-online (NetworkManager-wait-online.service) is started
* NetworkManager tries to configure network
* the first try of using dhclient fails with timeout for some reasons
* the second try of running dhclient completes successfully (NMs tries himself)
We get a working network, but it takes more that 30 seconds.
NetworkManager-wait-online.service fails, it may be a false negative
to checkers of network being online. It will also be a false positive signal
to start mounting network (CIFS, NFS etc.) shares, for example, because
they depend from network-online.target and network-online.target will become
reached right after NetworkManager-wait-online.service fails.
So, it makes sense to increase default timeout from 30 to 60 seconds.
@thaller wrote in https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/237
that there may be cases where, for example, incorrectly set up bridges
or just network may lead to delays when booting the system.
Yes, but:
* if there is no possibility to start trying to connect the network, e.g. if all network interfaces,
managed by NetworkManager, are DOWN, NM will not try to connect network and "nm-online -s" will
exit with 0 without waiting (so, this will not prolong start up of workstations or servers
when ethernet cable is just not plugged in)
* an additional potential 30 seconds delay seems to be less harmful then a false positive to start
mounting network shares or doing abything else too eraly, when an additional wait for a few seconds
would have prevented those things from failing.
All things considered, it seems reasonable to increase this timeout from 30 seconds to 1 minute (60 seconds).
Signed-off-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/675
Rework update_system_hostname() to use the new properties from the
hostname setting.
In the default configuration where all the 3 boolean properties
hostname.{from-dhcp,from-dns,only-from-default} are true, the behavior
is the same as before.
When a new active connection is created, it gets added at the
beginning of manager's list. This means that the list contains most
recently activated connections first. Since the list is doubly-linked,
it is possible to efficiently iterate in both directions, so the order
of the list is mostly a matter of convention.
I think it is preferable to have oldest active connections at the
beginning of the list; let's reverse the order.
In most places where the list is iterated, the order doesn't
matter. Where it does, use the *_prev() variant to maintain the old
iteration order.
The following merge request in ModemManager introduces a more or less
common timeout value for the connection attempts in all plugin and
protocol implementations:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/391
The value chosen by default for the steps that may take long to
complete in a connection attempt is 180s, and 120s for the steps in
the disconnection path.
Until now, every different plugin or protocol had a different timeout
value, all of them <= 180s, and with that change in ModemManager, the
values are now aligned for all.
Note, though, that this does not mean that a connection attempt will
take always less than 180s, as there may be multiple other steps in
addition to the one that took the maximum timeout. The value chosen
for NetworkManager is a compromise between the new defaults from MM
and what the user would expect under e.g. very low quality conditions.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/678
