This function is badly named, because it has no NMHostnameManager self
argument. It's just a simple function that entirely operates on a string
argument.
Move it away from "nm-hostname-manager.h" to "libnm-glib-aux/nm-shared-utils.h".
Hostname handling is complicated enough. Simple string validation
functions should not obscure the view on the complicated parts.
Using the guint source ID always requires an additional hash lookup
during removal to find the real source instance. Use instead the
underlying GSource instance.
When we are a client in the group we may be assigned an address by the
group owner. Use this address if it is available, but only if we are in
AUTO configuration mode.
NMConfigData is immutable and with the previous commit are the strings
already cached internally. There is no need to clone it.
Of course, the callers must not assume that the string stays alive after
a config reload (SIGHUP), where the NMConfigData might change. So they
are not always alive, but long enough for all callers to avoid cloning
the string.
In presence of a IPv6 deprecated address and a non-deprecated one, the
latter will be used by kernel for new connections according to RFC
6724 section 5 (Source Address Selection). Prefer it also to lookup a
hostname via reverse DNS.
While at it, also prefer non-link-local addresses over link-local
ones.
The new function resolve an address via DNS, first by using
systemd-resolved (disabling synthesized results) and then by spawning
the daemon helper.
Trying systemd-resolved via D-Bus before spawning the helper is
important to get a correct result. Suppose that resolv.conf points to
the local stub listener at 127.0.0.53; if NM only spawns the helper,
the helper will query the local systemd-resolved which could return a
synthesized result.
Therefore, we first query systemd-resolved with NO_SYNTHESIZE and
then, in case of error, we spawn the helper.
(cherry picked from commit 27eae4043b)
This setting can't be handled IWD (e.g. during autoactivations performed
by IWD) and although for manual activations NM will probably check it,
there's no reason for the IWD backend to restrict new profiles to one
interface plus when running IWD the udev permanent interface naming is
likely to be broken.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/886
(cherry picked from commit 35a1d89a96)
Found by valgrind.
Fixes: 4154d9618c ('bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data')
(cherry picked from commit 6813a4fe75)
- always remember priv->last_state_dir that we received via
D-Bus. Only later, during get_config_path() we will check
whether the path is valid.
- remember in priv->warned_state_dir the full path for
which we warned. We want to print a warning for each
path once, if the path changes, then we also want a new
warning. A boolean flag cannot express that.
NetworkManager supports a very limited set of qdiscs. If users want to
configure a unsupported qdisc, they need to do it outside of
NetworkManager using tc.
The problem is that NM also removes all qdiscs and filters during
activation if the connection doesn't contain a TC setting. Therefore,
setting TC configuration outside of NM is hard because users need to
do it *after* the connection is up (for example through a dispatcher
script).
Let NM consider the presence (or absence) of a TC setting in the
connection to determine whether NM should configure (or not) qdiscs
and filters on the interface. We already do something similar for
SR-IOV configuration.
Since new connections don't have the TC setting, the new behavior
(ignore existing configuration) will be the default. The impact of
this change in different scenarios is:
- the user previously configured TC settings via NM. This continues
to work as before;
- the user didn't set any qdiscs or filters in the connection, and
expected NM to clear them from the interface during activation.
Here there is a change in behavior, but it seems unlikely that
anybody relied on the old one;
- the user didn't care about qdiscs and filters; NM removed all
qdiscs upon activation, and so the default qdisc from kernel was
used. After this change, NM will not touch qdiscs and the default
qdisc will be used, as before;
- the user set a different qdisc via tc and NM cleared it during
activation. Now this will work as expected.
So, the new default behavior seems better than the previous one.
https://bugzilla.redhat.com/show_bug.cgi?id=1928078
Mimic the behaviour of wpa_supplicant where the "secure" identity in
TTLS and PEAP (802-1x.identity) is used as a fallback in the anonymous
identity (802-1x.anonymous_identity) if that is not provided. This is
needed to keep the profiles compatible between the two wifi backends,
for users of poorly configured WPA-Enterprise networks that require the
user login to be sent in phase 1 or in both phases.
The code responsible for this mechanism in wpa_supplicant, at the time
of writing, is
https://w1.fi/cgit/hostap/tree/src/eap_peer/eap.c?id=c733664be9dd3763c03f2da2cb32a23775dde388#n1688
and offers no comment about the privacy implications.
Since the [main].iwd-config-path functionality, where NM watches for
NMSettingsConnection changes and update IWD network config files with
new settings, has proven to work without issues so far, enable it by
default. Instead of hardcoding /var/lib/iwd as the value, and since the
value can't be probed at NM compile time, query it from IWD's recently-
added D-Bus interface for settings when [main].iwd-config-path is either
missing or set to the new value "auto".
Coverity doesn't like the previous code:
Error: RESOURCE_LEAK (CWE-772): [#def34] [important]
NetworkManager-1.31.5/src/core/devices/team/nm-device-team.c:835: alloc_fn: Storage is returned from allocation function "g_strdup".
NetworkManager-1.31.5/src/core/devices/team/nm-device-team.c:835: noescape: Resource "g_strdup(config)" is not freed or pointed-to in "g_strdelimit".
NetworkManager-1.31.5/src/core/devices/team/nm-device-team.c:835: leaked_storage: Failing to save or free storage allocated by "g_strdup(config)" leaks it.
# 833| char *sanitized_config;
# 834|
# 835|-> sanitized_config = g_strdelimit(g_strdup(config), "\r\n", ' ');
# 836| err = teamdctl_port_config_update_raw(priv->tdc, slave_iface, sanitized_config);
# 837| g_free(sanitized_config);
Maybe this works better.
dhcp-anycast-address is only set by OLPC mesh device. It's ugly to have
this in form of a nm_device_set_dhcp_anycast_address() method, because
that means to cache the address in NMDevice. Meaning, we have more state
in NMDevice, where it's not clear where it comes from.
Instead, whenever we need to DHCP anycast address, as the subclass to
provide it (if any). This way, it gets extracted from the currently
applied connection at the moment when it is needed. Beyond that, the
setting is not duplicated/cached in NMDevice anymore.
Kernel will coerce values like
ethtool -A eth0 autoneg on rx off
to have autonet still on.
Also, if autoneg on the interface is enabled, then `ethtool -A eth0 tx off`
has no effect.
In NetworkManager, the user cannot configure "autoneg on" together with
any rx/tx settings. That would render the profile invalid. However, we
also need to take care that a profile
nmcli connection add ... ethtool.pause-autoneg ignore ethtool.pause-tx off
really means off. That means, we must coerce an unspecified autoneg
setting to "off".
Currently we commit the MTU to the device when updating the IP
configuration, or when a port device is added to the controller. This
means that for a connection with DHCP, the MTU is set only after DHCP
has completed. In particular, if DHCP doesn't complete and the
connection has an infinite timeout, the MTU is never set.
_commit_mtu() tracks different sources for the MTU of a device, and
each source has a different priority. Among these sources there are
the parent link (for VLANs), a dynamic IP configuration (DHCP, PPP)
and the connection profile.
A MTU from the connection always has the highest priority and
overrides other sources.
Therefore, if the connection specifies an MTU it can be applied at
stage2, even before configuring IP addressing.
https://bugzilla.redhat.com/show_bug.cgi?id=1890234https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/859
If the device is still unmanaged by platform-init (which means that
udev didn't emit the event for the interface) when the device gets
realized, we currently clear the assume state. Later, when the device
becomes managed, NM is not able to properly assume the device using
the UUID.
This situation arises, for example, when NM already configured the
device in initrd; after NM is restarted in the real root, udev events
can be delayed causing this race condition.
Among all unamanaged flags, platform-init is the only one that can be
delayed externally. We should not clear the assume state if the device
has only platform-init in the unmanaged flags.
D-Bus 1.3.1 (2010) introduced the standard "PropertiesChanged" signal
on "org.freedesktop.DBus.Properties". NetworkManager is old, and predates
this API. From that time, it still had it's own PropertiesChanged signal
that are emitted together with the standard ones. NetworkManager
supports the standard PropertiesChanged signal since it switched to
gdbus library in version 1.2.0 (2016).
These own signals are deprecated for a long time already ([1], 2016), and
are hopefully not used by anybody anymore. libnm-glib was using them and
relied on them, but that library is gone. libnm does not use them and neither
does plasma-nm.
Hopefully no users are left that are affected by this API break.
[1] 6fb917178a
Introducing ethtool PAUSE support with:
* ethtool.pause-autoneg on/off
* ethtool.pause-rx on/off
* ethtool.pause-tx on/off
Limitations:
* When `ethtool.pause-autoneg` is set to true, the `ethtool.pause-rx`
and `ethtool.pause-tx` will be ignored. We don't have warning for
this yet.
Unit test case included.
Signed-off-by: Gris Ge <fge@redhat.com>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/829
It's still not a very good name, but it seems better then
NMUtilsShareRules.
Currently, NMFirewallConfig is mostly about masquerading for shared
mode. But in practice, it's a piece of configuration for something to
configure in the firewall (the NAT and filter rules).
Previously, NMUtilsShareRules basically was tracking a list of command
line arguments, and during apply(), it would spawn the (iptables)
processes.
But in practice, this list was always pre-determined by a few
parameters, the interface name and the subnet. Instead of keeping the
list of arguments, only keep those few parameters. And generate the list
of arguments only for the short time when we need them.
The difference is that we will want to support nftables too. Later,
we can just generate a different list of commands, but there is no
need to keep this list around.
nm_act_request_set_shared() already calls nm_utils_share_rules_apply().
Calling it twice, is pretty bad because during deactivate we will only
remove one of each duplicate rule.
Fixes: 701654b930 ('core: refactor tracking of shared-rules to use NMUtilsShareRules')
Networks offering WPA2 and WPA3/SAE at the same time are in WPA3 hybrid
mode. In this case the PSK passphrase rules that apply need to be the
WPA2 rules, so we shouldn't use "sae" as key-mgmt. Also our wifi card
might not support SAE and we want to make sure WPA2 eventually gets used
in that case.
So use "wpa-psk" as key-mgmt method in case an AP is in WPA3 hybrid
mode.
We will add a general "firewall-manager", so rename the firewalld related
file. This commit only renames the file. The next commit will change the
symbol naming.
"nm-device.c" is huge, and it does complicated things like handling the
state of the device and IP configuration.
It also contains simpler, individual functions, like converting enums to
strings. Let's move those trivial functions to a new module, so that the
remaining part is smaller.
"nm-device-utils.[ch]" should only contain simpler functions that have
no complex behavior or state.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/840
For infiniband, request_broadcast is automatically (and always) enabled.
Otherwise, we usually don't enable it, and (unlike systemd-networkd),
there is currently no configuration option to enable it.
Still honor the new udev property that can indicate to enable the flag
per device.
See-also: https://github.com/systemd/systemd/pull/ ### 19346
The DHCP client has potentially a large number of options,
including boolean options (flags). It is cumbersome to implement
them one by one. Instead, make more prominent use of NMDhcpClientFlags.
