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.
ntables backend is not yet well tested. Don't flip the default yet
but for now always use iptables.
Once nftables is shown to work well, revert this patch.
Add support for nftables, as a second backend beside iptables (firewalld
still missing).
Like iptables, choose to call the `nft` tool. The alternative would be
to use libnftables or talk netlink.
It's ugly to blocking wait for a process to complete. We already do that
for iptables, but we better should not because we should not treat other
processes as trusted and not allow untrusted code to block NetworkManager.
Fixing that would require a central manager that serializes all requests.
Especially with firewalld support, this will be interesting again,
because we don't want to synchronously talk D-Bus either.
For now, `nft` is still called synchronously. However, the internal
implementation uses an asynchronous function. That currently
serves no purpose except supporting a timeout. Otherwise, the only
reason why this is asynchronous is that I implemented this first, and
I think in the future we want this code to be non-blocking. So, instead
of dropping the asynchronous code, I wrap it in a synchronous function
for now.
The configured nft table is:
table inet nm-shared-eth0 {
chain nat_postrouting {
type nat hook postrouting priority srcnat; policy accept;
ip saddr 192.168.42.0/24 ip daddr != 192.168.42.0/24 masquerade
}
chain filter_forward {
type filter hook forward priority filter; policy accept;
ip daddr 192.168.42.0/24 oifname "eth0" ct state { established, related } accept
ip saddr 192.168.42.0/24 iifname "eth0" accept
iifname "eth0" oifname "eth0" accept
iifname "eth0" reject
oifname "eth0" reject
}
}
The new name makes it more generic, because the limitation exists
for iptables chains. Everything else (iptables comments, nftables
tables) has no such length limit.
Our clang-format style doesn't work well with these gtk-doc
tags.
For NetworkManager core, we don't use glib-mkenums. Thus, these
comments serve no purpose. Drop them for better formatting.
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
Probably pid_t is always signed, because kill() documents that
negative values have a special meaning (technically, C would
automatically cast negative signed values to an unsigned pid_t type
too).
Anyway, NMDhcpClient at several places uses -1 as special value for "no
pid". At the same time, it checks for valid PIDs with "pid > 1". That
only works if pid_t is signed.
Add a static assertion for that.
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 not the task of the writer to mangle/normalize profiles. If a profile
for a virtual device can have an [ethernet] setting, then unsuitable values
like s390 options must be either rejected by nm_connection_verify() or normalized
by nm_connection_normalize(). In no way it's right that the writer simple
pretends they are not set.
Coverity says:
Error: ALLOC_FREE_MISMATCH (CWE-762):
NetworkManager-1.31.3/src/core/dhcp/nm-dhcp-systemd.c:234: alloc: Allocation of memory which must be freed using "free".
NetworkManager-1.31.3/src/core/dhcp/nm-dhcp-systemd.c:447: free: Calling "_nm_auto_g_free" frees "routes" using "g_free" but it should have been freed using "free".
# 445| }
# 446| NM_SET_OUT(out_options, g_steal_pointer(&options));
# 447|-> return g_steal_pointer(&ip4_config);
# 448| }
# 449|
Fixes: acc0d79224 ('systemd: merge branch 'systemd' into master')
Coverity says:
Error: ALLOC_FREE_MISMATCH (CWE-762):
NetworkManager-1.31.3/src/core/tests/test-systemd.c:261: alloc: Allocation of memory which must be freed using "free".
NetworkManager-1.31.3/src/core/tests/test-systemd.c:274: free: Calling "_nm_auto_g_free" frees "exp2_arr" using "g_free" but it should have been freed using "free".
# 272| g_assert_cmpmem(expected_arr, expected_len, exp3_arr, exp3_len);
# 273| }
# 274|-> }
# 275|
# 276| #define _test_unbase64mem(base64, expected_str) \
Error: ALLOC_FREE_MISMATCH (CWE-762):
NetworkManager-1.31.3/src/core/tests/test-systemd.c:270: alloc: Allocation of memory which must be freed using "free".
NetworkManager-1.31.3/src/core/tests/test-systemd.c:274: free: Calling "_nm_auto_g_free" frees "exp3_arr" using "g_free" but it should have been freed using "free".
# 272| g_assert_cmpmem(expected_arr, expected_len, exp3_arr, exp3_len);
# 273| }
# 274|-> }
# 275|
# 276| #define _test_unbase64mem(base64, expected_str) \
Fixes: 0298d54078 ('systemd: expose unbase64mem() as nm_sd_utils_unbase64mem()')
Found by Coverity:
Error: RESOURCE_LEAK (CWE-772):
NetworkManager-1.31.3/src/core/nm-config-data.c:450: alloc_fn: Storage is returned from allocation function "nm_config_data_get_value".
NetworkManager-1.31.3/src/core/nm-config-data.c:450: var_assign: Assigning: "str" = storage returned from "nm_config_data_get_value(self, "main", "auth-polkit", (enum [unnamed type of NMConfigGetValueFlags])6)".
NetworkManager-1.31.3/src/core/nm-config-data.c:454: noescape: Resource "str" is not freed or pointed-to in "nm_auth_polkit_mode_from_string".
NetworkManager-1.31.3/src/core/nm-config-data.c:465: leaked_storage: Variable "str" going out of scope leaks the storage it points to.
# 463| NM_SET_OUT(out_invalid_config, FALSE);
# 464|
# 465|-> return auth_polkit_mode;
# 466| }
# 467|
Fixes: 6d7446e52f ('core: add main.auth-polkit option "root-only"')
"string" is leaked in the error case. But in practice, this cannot
happen because nm_bridge_vlan_to_str() cannot fail.
While at it, replace GString by NMStrBuf.
Thanks Coverity:
Error: RESOURCE_LEAK (CWE-772):
NetworkManager-1.31.3/src/core/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:1565: alloc_fn: Storage is returned from allocation function "g_string_new".
NetworkManager-1.31.3/src/core/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:1565: var_assign: Assigning: "string" = storage returned from "g_string_new("")".
NetworkManager-1.31.3/src/core/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:1572: leaked_storage: Variable "string" going out of scope leaks the storage it points to.
# 1570| vlan_str = nm_bridge_vlan_to_str(vlan, error);
# 1571| if (!vlan_str)
# 1572|-> return FALSE;
# 1573| if (string->len > 0)
# 1574| g_string_append(string, ",");
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).
When we configure iptables rules, we really do two independent
steps: enable masquerading and do some filtering.
As such, introduce a helper method _share_iptables_set_masquerade() for
the masquerading part.
nm_utils_share_rules_apply() is at the moment a bit odd, because
of the order in which we add/remove the rule. This will get better next.
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.
There can also be APs which don't do wpa-psk, but do support
wpa-psk-sha256, so we should match all AKM suites the AP offers to
determine the security type we want to assign it.
According to [1], the only suitable FT cipher suite for WPA3 Enterprise
192-bit mode is "FT over 802.1X, SHA-384", so enable that in case of
key-mgmt is WPA-EAP-SUITE-B-192 to support FT in that case too.
[1] https://mrncciew.com/2020/08/17/wpa3-enterprise/
As mentioned in the wpa_supplicant reference config, when setting PMF to
required with WPA2 (personal or enterprise) authentication, we want to
only enable SHA256 and upwards as HMAC. So enforce that by not passing
WPA-PSK and WPA-EAP to the config in case pmf is set to REQUIRED.
When using modern WPA3 encryption like owe, sae or wpa-eap-suite-b-192
without fallbacks (so not WPA3+WPA2), protected management frames are
required to be enabled by the specification.
For wpa-eap-suite-b-192 we already do this and force PMF to REQUIRED, we
should also do it for OWE and SAE.
Refactor the generation of the key_mgmt option of the wpa_supplicant
config we generate. The goal of this is to lay out all the cases we
support more obviously and to make it a bit clearer that our key-mgmt
property of NMSettingsWirelessSecurity is not the same as the "key_mgmt"
config we set in wpa_supplicant.
