This is mostly done. What is not done is to delay the ACTIVATED state
until the connectivty check passed. Delaying that might be problematic
and should only be done as opt-in. Unclear whether that would ever be useful
though.
../src/nm-manager.c: In function periodic_update_active_connection_timestamps:
../src/nm-manager.c:7358:43: error: t may be used uninitialized in this function [-Werror=maybe-uninitialized]
nm_settings_connection_update_timestamp (nm_active_connection_get_settings_connection (ac),
^
Fixes: 6f3ae8a563 ('core: in periodic_update_active_connection_timestamps() use same timestamp')
We don't need the mask argument. If the caller wants to check only for certain
flags, she can do that right away with
NM_FLAGS_ANY (nm_settings_connection_autoconnect_blocked_reason_get (sett_con), flags)
When the secrets for a connection are updated, unblock autoconnection
in case it had been blocked previously due to bad or no
secrets. Otherwise we would need to manually activate the connection
or restart NM to get another try with the new secrets.
As commit ccfe5fec8d ('wifi: don't autoconnect to networks that have
never been successful') explains, Wi-Fi profiles only autoconnected
if they had no or a positive timestamp.
The problem that tried to solve is when a user accidentally clicks on a
Wi-Fi network in applet. Then the created profile may not be usable
(because of wrong credentials). To avoid indefinitely to autoconnect,
uch a profile will have a timestamp of 0, which prevents further
auto activations.
However, I find that problematic.
An important use case is pre-deploying profiles. In that case, the user
cannot set the timestamp, because the timestamp cache
/var/lib/NetworkManager/timestamps is internal, undocumented API. Also,
ifcfg-rh doesn't support the timestamp and anyway, does the timestamp
of the NMConnection does not get honored (only the one from the
timestamps file).
Maybe that could be an alternative solution here, to allow the user to
mark profiles as "I really want it to autoconnect". But that seems
unnecessary and wrong to me.
The problem really is that the user cannot do anything to ensure that
autoconnect will work tomorrow (short of editing the timestamps
database). The problem is that the property of whether a profile
every connected successfully is not in direct control of the user (it
depends on external conditions).
If the user has bogus profiles configured, those profiles should be
deleted (or autoconnect disabled) and not keep autoconnect blocked.
Also note that if you are at home and accidentally click on your
neighbour's Wi-Fi network, then you presumably still also have a working
profile to your own network. That usable profile will have a more
recent timestamp and be preferred during autoconnect already.
This reverts commit ccfe5fec8d.
https://bugzilla.redhat.com/show_bug.cgi?id=1781253
Updating the timestamp marks the keyfile database as dirty. Avoid
that, if there is no change. Of course, nm_key_file_db_set_value()
itself already checks whether the are any changes, and does nothing
if there aren't.
Simply perform the check earlier, to do nothing.
When performing a synchronous action together (like iterating
over all settings and set the current timestamp), it's nicer
to pretend that all this would happen instantaneously. That means,
ensure we use the same timestamp throughout.
On a minor point, there really is no need to call time() multiple times.
Code like
»···»···if (strcmp (tag, "net.ifnames") == 0)
»···»···»···net_ifnames = strcmp (argument, "0") != 0;
is really hard to understand (at least to me). Compare to
»···»···if (nm_streq (tag, "net.ifnames"))
»···»···»···net_ifnames = !nm_streq (argument, "0");
The autoneg/speed ethtool settings are important. If they are wrong,
the device might not get any carrier. Having no carrier means that
you may be unable to activate a profile (because depending on
configuration, carrier is required to activate a profile).
Since activating profiles are the means to configure the link settings
in NetworkManager, and activating a profile can be hampered by wrong link
settings, it's important to reset the "correct" settings, when deactivating
a profile.
"Correct" in this case means to restore the settings that were present
before NM changed the settings. Presumably, these are the right once.
Beyond that, in the future it might make sense to support configuring
the default link settings per device. So that NM will always restore a
defined, configured, working state. The problem is that per-device
settings currently are only available via NetworkManager.conf, which
is rather inflexible.
Also, when you restart NetworkManager service, it leaves the interface
up but forgets the previous setting. That possibly could be fixed by
persisting the previous link state in /run. However, it's not
implemented yet.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/356https://bugzilla.redhat.com/show_bug.cgi?id=1807171
nm_platform_ethtool_init_ring() only has one caller. It's simpler to
drop the function and implement it at the only place where it is needed.
Maybe there could be a place for a function to initialize NMEthtoolRingState,
one option after the other. However, at the moment there is only one
user, so don't implement it.
This fixes various minor issues:
- the function had a NMPlatform argument, although the argument
is not used. Thus function merely operates on a NMEthtoolRingState
instance and shouldn't have a nm_platform_*() name.
- nm_platform_ethtool_init_ring() returned a boolean, but all
code paths (except assertion failures) returned success.
- as the function returned an error status, the caller was compelled
to handle an error that could never happen.
- the option was specified by name, although we already have a more
efficient way to express the option: the NMEthtoolID. Also, the
caller already needed to resolve the name to the NMEthtoolID, so
there was no need to again lookup the ID by name.
Imagine you have a veth device. That device supports certain offload features
(like "ethtool.feature-rx-checksum") but doesn't support any ring
options. Even trying to read the current ring settings will fail.
If you try to activate that profile, NMDevice previously would always
try to fetch the ring options and log a warning and extra debugging
messages:
<trace> [1590511552.3943] ethtool[31]: ETHTOOL_GRINGPARAM, v: failed: Operation not supported
<trace> [1590511552.3944] ethtool[31]: get-ring: failure getting ring settings
<warn> [1590511552.3944] device (v): ethtool: failure getting ring settings (cannot read)
It does so, although you didn't specify any ring settings and there
was no need to fetch the ring settings to begin with.
Avoid this extra logging by only fetching the ring option when they
are actually required.
Setting the kernel token is not strictly necessary as the IPv6 address
is generated in userspace by NetworkManager. However it is convenient
for users to see that the value set in the profile is also set in the
kernel, to confirm that everything is working as expected.
The kernel allows setting a token only when 'accept_ra' is 1:
temporarily flip it if necessary. Unfortunately this will also
generate an additional Router Solicitation from kernel, but this is
not a big issue.
When a team device is assumed, we skip stage1 and imply that teamd is
already running. If this doesn't happen (for example because teamd was
manually stopped or because the interface was created in the initrd),
the team interface will continue processing traffic but will not react
to changes in the environment (e.g. carrier changes). Ensure that
teamd is running for assumed devices.
Rework qdisc synchronization. The previous implementation added all
known qdiscs and removed unneeded ones from platform; this had some
problems:
- kernel doesn't allow to add (with exclusive flag) a qdisc if one
with the same parent already exists;
- if we use the replace flag instead of add, then it becomes possible
to add a new qdisc with the same parent of an existing one. However
if the existing qdisc is of the same kind, kernel will try to to
change() it, which fails for some qdiscs (e.g. sfq).
- kernel doesn't allow to delete a qdisc with handle of zero because
that is the default qdisc and can only be replaced;
Fix that.
Usually stage1 is skipped for external or assumed devices. Add a
mechanism to call stage1 for all devices, similarly to what was
already done for stage2.
