At least with my supplicant, the capability is called
all-upper-case "FAST".
The check used case-insensitive, but that was broken
by a previous change.
Fixes: 9f5f141100
Basically to silence gcc that is not smart enough to understand how does
.initialized and .value relate.
src/devices/nm-device.c: In function '_commit_mtu':
src/devices/nm-device.c:6754:15: error: 'ip6_mtu_sysctl.value' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (ip6_mtu && ip6_mtu != _IP6_MTU_SYS ()) {
^
(cherry picked from commit 7ce805d49d)
Basically to silence gcc that is not smart enough to understand how does
.initialized and .value relate.
src/devices/nm-device.c: In function '_commit_mtu':
src/devices/nm-device.c:6754:15: error: 'ip6_mtu_sysctl.value' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (ip6_mtu && ip6_mtu != _IP6_MTU_SYS ()) {
^
This allows a user to restore the previous behavior where NetworkManager
would not reconfigure the MTU during device activation, if no MTU is
available (commit "22e8af6 device: set a per-device default MTU on
activation").
Well, not exactly. The previous behavior was to use per-connection
configuration, then DHCP provided value, or finally leave the MTU
unspecified.
Now, we prefer a per-connection configuration, followed by a global
connection default. If "ethernet.mtu=0", the MTU is left unspecified.
In absense of a global connection default, the value from DHCP is used
or finally a per-device-type default. That is effectively 1500 for most
types, except for infiniband where the MTU is still left unspecified.
Add code to nm-device-macsec.c to support the creation of macsec
connection. Most of the code for controlling wpa_supplicant is copied
from nm-device-ethernet.c and probably could be consolidated in some
ways.
The new NMSettingMacsec contains information necessary to establish a
MACsec connection. At the moment we support two different MACsec
modes, both using wpa_supplicant: PSK and EAP.
PSK mode is based on a static CAK key for the MACsec key agreement
protocol, while EAP mode derives keys from a 802.1x authentication and
thus requires the presence of a NMSetting8021x in the connection.
In absence of an explicit MTU (either via user configuration, PPP or
DHCP), set a default MTU on activation that depends on the device type.
We only want to do that on the very first call to _commit_mtu(). Later
calls (for example in response to new DHCP leases) skip over this step.
This means, on activation the MTU will always be reset to a sensible
value instead of preserving whatever was left from a previous
configuration.
This does not cover setting the MTU from the VPN plugin :(
When you have a connection with "ethernet.mtu=0 (auto)", the MTU is not set
during activation. That means, the effective MTU depends on the previous
MTU configuration of the device. Which in turn, depends on the
previously active connection, as we don't reset the MTU on deactivation.
Restore the previous MTU on deactivation iff NetworkManager changed
the MTU during device activation.
Don't have this mtu_desired variable. All the data is readily available
without redundancy. E.g. the applied-connection contains everything
we need to know. Just get it as needed.
Also drop apply_mtu_from_config(). It didn't take into account
the MTU settings beside NMSettingWired.
Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into
priv->ip4_config. NMIP4Config now only tracks the MTU from the various
non-user-config sources, but the user config is no longer merged back
into the composite.
It is wrong that nm_ip4_config_set_mtu() tries to ~merge~ the new MTU
with the existing. All callers of nm_ip4_config_set_mtu() want that the
new value prevails.
That is also already the case because the DHCP clients and PPP manager set
the MTU on a newly created NMIP4Config instance, thus their value is taken.
Similarly, the final merge with NM_IP_CONFIG_SOURCE_USER also prevails as the
source has the highest priority.
The setter should just set. The only place where we want the merge behavior
is in nm_ip4_config_merge(), where it is now implemented in-place.
For example, nm_ip4_config_replace() very much wants that the new value
wins, regardless of the previous setting. Using nm_ip4_config_set_mtu()
with the merge behavior was wrong because it means that the MTU of NMDevice's
composite can never be raised again (for example with a new DHCP event).
The problem is that the bridge's MTU cannot be larger then the slaves'.
Configuring such a setting results in an error being logged and the
activation proceeds (without applying the desired MTU).
Unclear how to fix that best.
Instead of overwriting ip4_config_pre_commit(), add a new function
get_mtu().
This also adds a default value in case there is no user-configuration.
This will allow us later to reset a default MTU based on the device
type.
