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.
When searching an element that is lower than the first list element (for
example RTNL type "batadv"), imax will be -1 after the last iteration.
Use int instead of unsigned to make the termination condition imin > imax
work in this case. This fixes NetworkManager crashing due to an
out-of-bounds array access whenever interfaces of such types exist.
Fixes: 19ad044359 ('platform: use binary search to lookup NMLinkType for rtnl_type')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/515
We are going to expose some of this API in libnm.
The name "gendata" (for "generic data") is not very suited. Instead,
call the public API nm_setting_option_*(). This also brings no naming
conflict, because currently no API exists with such naming.
Rename the internal API, so that it matches the API that we are going
to expose next.
We already have NMEthtoolID to handle coalesce options in a way that is
convenient programmatically. That is, we can iterate over all valid
coalesce options (it's just an integer) and use that in a more generic
way.
If NMEthtoolCoalesceState names all fields explicitly, we need explicit
code that names each coalesce option. Especially since NMEthtoolCoalesceState
is an internal and intermediate data structure, this is cumbersome
and unnecessary.
Thereby it also fixes the issue that nm_platform_ethtool_init_coalesce() has a
NMPlatform argument without actually needing it.
nm_platform_ethtool_init_coalesce() does not operate on a NMPlatform
instance, and should not have the appearance of being a method of
NMPlatform.
All other users name a similar variable "coalesce" (or "coalesce_new",
"coalesce_old"). Rename the variables, to don't use different names for
similar uses.
nm-device now applies ethtool ring settings during stage 2 "device
config" of the connection activation.
ring settings will be then restored (according to what the state
was before the connection got activated on the device) when the
connection is deactivated during the device cleanup.
One thing to be noted is that unset ring settings (in the profile)
will not be touched at all by NetworkManager so that if the NIC driver
sets some default values these will be preserved unless specifically
overridden by the connection profile.
https://bugzilla.redhat.com/show_bug.cgi?id=1614700
Only in one moment we need the old and requested settings together:
during _ethtool_coalesce_set(). But for that we shouldn't track both
states in "NMEthtoolCoalesceState".
Simplify "NMEthtoolCoalesceState" to only contain one set of options.
By tracking less state, the code becomes simpler, because you don't
need to wonder where the old and requested state is used.
When the interface is in IPv4 or IPv6 shared mode and the user didn't
specify an explicit zone, use the nm-shared one.
Note that masquerade is still done through iptables direct calls
because at the moment it is not possible for a firewalld zone to do
masquerade based on the input interface.
The firewalld zone is needed on systems where firewalld is using the
nftables backend and the 'iptables' binary uses the iptables API
(instead of the nftables one). On such systems, even if the traffic is
allowed in iptables by our direct rules, it can still be dropped in
nftables by firewalld.
For ip-tunnel modes that encapsulate layer2 packets (gretap and
ip6gretap) we allow the presence of an ethernet setting in the
connection and honor the cloned-mac-address specified in it.
For all other modes, the ethernet setting is removed during
normalization, but a value different from 'preserve' could be set via
global default.
The kernel doesn't allow setting a MAC for layer3 devices, don't do
it.
When parsing user input if is often convenient to allow stripping whitespace.
Especially with escaped strings, the user could still escape the whitespace,
if the space should be taken literally.
Add support for that to nm_utils_buf_utf8safe_unescape().
Note that this is not the same as calling g_strstrip() before/after
unescape. That is, because nm_utils_buf_utf8safe_unescape() correctly
preserves escaped whitespace. If you call g_strstrip() before/after
the unescape, you don't know whether the whitespace is escaped.
nm-device now applies ethtool coalesce settings during stage 2 "device
config" of the connection activation.
Coalesce settings will be then restored (according to what the state
was before the connection got activated on the device) when the
connection is deactivated during the device cleanup.
One thing to be noted is that unset coalesce settings (in the profile)
will not be touched at all by NetworkManager so that if the NIC driver
sets some default values these will be preserved unless specifically
overridden by the connection profile.
https://bugzilla.redhat.com/show_bug.cgi?id=1614700
NM_SET_OUT() macro already has an "if" condition to only do
anything if the output pointer is not NULL.
As such, we don't need to check first. In practice, this only reorders
the checks, which the compiler may anyway do.
Note that above the checks are still relevant, because we want to
avoid the more expensive parsing, if we don't care about the result.
