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.
The field priv->mtu should contain what is actually configured
on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU
property.
That shall be handled distinct from what we want to configure as
MTU on the device.
Refactor the handling of MTU with a new functoin _set_mtu() which looks
at the desired paramters and compares it with what is configured (in
platform and sysctl). Then it makes a decision what to configure.
Mark priv->mtu/priv->ip_mtu/ priv->ip6_mtu as const to highlight the
places that explicitly set their mutable aliases priv->mtu_/
priv->ip_mtu_/priv->ip6_mtu_.
Also, NM_DEVICE_MTU property is read-only. It cannot be set
via g_object_set().
Also, clear priv->mtu in nm_device_unrealize().
bool:1 bitfields allow for tighter packing and are guaranteed to be
strictly 0 or 1 (contrary to gboolean's typedef for int). Not that it
matters too much, but it's favorable.
Especially, because each device has several of these ip-config instances,
we might save a few bytes for no(?) downsides.
We end up calling nmp_cache_id_init_*() a lot to initialize stack-allocated
cache-ids to lookup the NMMultiIndex. There is no need to memset() it to
zero, because all relevant fields are supposed to be set explicitly.
Use %u for unsigned type and cast the guint32 to (unsigned).
While at it, increase the stack-allocated buffer to 64 bytes
(it doesn't hurt) and use nm_sprintf_buf().
libnm-core/nm-setting-8021x.c:658: Warning: NM: nm_setting_802_1x_set_ca_cert: unknown parameter 'value' in documentation comment, should be 'cert_path'
libnm-core/nm-setting-8021x.c:1023: Warning: NM: nm_setting_802_1x_set_client_cert: unknown parameter 'value' in documentation comment, should be 'cert_path'
libnm-core/nm-setting-8021x.c:1331: Warning: NM: nm_setting_802_1x_set_phase2_ca_cert: unknown parameter 'value' in documentation comment, should be 'cert_path'
libnm-core/nm-setting-8021x.c:1702: Warning: NM: nm_setting_802_1x_set_phase2_client_cert: unknown parameter 'value' in documentation comment, should be 'cert_path'
libnm-core/nm-setting-8021x.c:2027: Warning: NM: nm_setting_802_1x_set_private_key: unknown parameter 'value' in documentation comment, should be 'key_path'
libnm-core/nm-setting-8021x.c:2374: Warning: NM: nm_setting_802_1x_set_phase2_private_key: unknown parameter 'value' in documentation comment, should be 'key_path'
Fixes: 2b09cee6fa
We allow to reapply a connection with different id, uuid, stable-id, autoconnect value.
This is allowed for convenience, so that a user can reapply a connection that differs
in these fields. But actually, these fields cannot be reapplied. That
is, their new values are not considered and the old values are continued
to be used.
Thus, mangle the reapplied connection to use the original, actually used
values.
The stable-id for one activation cannot actually change. This is also, because we cache it
as priv->current_stable_id. Still, allow reapply with a differing stable-id for convenience.
It also used __bitwise and __force. It seems easier to rename
our versions since they are local to this one single header.
Also, undefine them afteerwards, so that we don't pollute the
preprocessor macro namespace.
https://github.com/systemd/systemd/pull/5061
The kernel already takes care of adding and updating temporary
addresses when an address with IFA_F_MANAGETEMPADDR flag is added or
updated; doing it also in nm_platform_ip6_address_sync() can overwrite
the changes done by kernel, especially because since commit
0a0bca9c7f ("ip6-config: sort addresses only when reading the
property value") there is no guarantee that temporary addresses are
before the public ones in the IPv6 configuration.
Still delete temporary addresses, but don't add or update them.
When a ifcfg-rh connection becomes unamanaged it is removed from the
connection list in NMSettings and marked as removed; it is however
kept alive in the plugin and can become managed again later. To avoid
failed assertions, the @removed flag of the NMSettingsConnection must
be cleared if the connection is not being disposed.
Usecase: when connecting to a public Wi-Fi with MAC address randomization
("wifi.cloned-mac-address=random") you get on every re-connect a new
IP address due to the changing MAC address.
"wifi.cloned-mac-address=stable" is the solution for that. But that
means, every time when reconnecting to this network, the same ID will
be reused. We want an ID that is stable for a while, but at a later
point a new ID should e generated when revisiting the Wi-Fi network.
Extend the stable-id to become dynamic and support templates/substitutions.
Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}".
Any unrecognized pattern is treated verbaim/untranslated.
"$$" is treated special to allow escaping the '$' character. This allows
the user to still embed verbatim '$' characters with the guarantee that
future versions of NetworkManager will still generate the same ID.
Of course, a user could just avoid '$' in the stable-id unless using
it for dynamic substitutions.
Later we might want to add more recognized substitutions. For example, it
could be useful to generate new IDs based on the current time. The ${} syntax
is extendable to support arguments like "${PERIODIC:weekly}".
Also allow "connection.stable-id" to be set as global default value.
Previously that made no sense because the stable-id was static
and is anyway strongly tied to the identity of the connection profile.
Now, with dynamic stable-ids it gets much more useful to specify
a global default.
Note that pre-existing stable-ids don't change and still generate
the same addresses -- unless they contain one of the new ${} patterns.
We require a network-id. Assert that it is set.
Also, we encode the stable-id as uint8. Thus, add
an assertion that we don't use more then 254 IDs.
If we ever make use of stable-type 255, we must extend
the encoding to allow for more values. The assertion
is there to catch that.
With commit 4f6c91d696, we aimed to
enable mac-address-randomization by default for Wi-Fi. That however
is not possible by default because it breaks various scenarios.
Also, later wifi.mac-address-randomization was deprecated in favor
of wifi.cloned-mac-address setting.
Both wifi.mac-address-randomization and wifi.cloned-mac-address support
global default values, so it is wrong to read a missing
mac-address-randomization as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
We set a dedicated route to reach the VPN gateway only if the parent
device has a gateway. If the parent device doesn't have a gateway (for
example in case of GSM connections) and the VPN gets the default
route, the VPN gateway will be contacted through the VPN itself, which
obviously doesn't work.
Set up a device route if the parent device doesn't provide a gateway.
https://bugzilla.redhat.com/show_bug.cgi?id=1403660
