The public property NM_DEVICE_ACTIVATION_REQUEST exposes the exported
D-Bus path. So, it's not sufficient to emit property changed signals
when changing the priv->act_request pointer, we must also react on
exporting/unexporting.
It's not clear whether this fixes an actual bug. Maybe, we never
export/unexport priv->act_request while the device tracks it.
But the code is pretty hard to follow and it's hard to verify
whether this is the case.
By hooking up to "notify::path", we can easily verify that such
a situtation cannot arise.
(cherry picked from commit 9ae5e6a54d)
Previously, we would have different functions like
- nm_match_spec_device_type()
- nm_match_spec_hwaddr()
- nm_match_spec_s390_subchannels()
- nm_match_spec_interface_name()
which all would handle one type of match-spec.
So, to get the overall result whether the arguments
match or not, nm_device_spec_match_list() had to stich
them together and iterate the list multiple times.
Refactor the code to have one nm_match_spec_device()
function that gets all relevant paramters.
The upside is:
- the logic how to evaluate the match-spec is all at one place
(match_device_eval()) instead of spread over multiple
functions.
- It requires iterating the list at most twice. Twice, because
we do a fast pre-search for "*".
One downside could be, that we have to pass all 4 arguments
for the evaluation, even if the might no be needed. That is,
because "nm-core-utils.c" shall be independend from NMDevice, it
cannot receive a device instance to get the parameters as needed.
As we would add new match-types, the argument list would grow.
However, all arguments are cached and fetching them from the
device's private data is very cheap.
(cherry picked from commit b957403efd)
After commit 553717bb1c ("device: don't set ip4_state=IP_FAIL for
ipv4.method=disabled"), we commit an empty IPv4 configuration when
IPv4 is disabled. This means that it's not necessary anymore to call
_commit_mtu() because the MTU will be set in
ip4_config_merge_and_apply().
(cherry picked from commit 714b18dcf7)
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)
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.
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.
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().
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().
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.
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.
The only implementations were there for tracking the parent device.
That is now donw via nm_device_parent_*(), parent_changed_notify()
and _parent_notify_changed().
Multiple subclasses have a parent/link interface (NMDeviceIPTunnel,
NMDeviceVlan). Tracking the parent interface properly is midly
complicated to get right. So, instead of repeating it in each
subclass, track it in the parent device.
Move the updating/setting of the ip-ifindex/ip-iface to one place.
Properties should be for the most part immutable/read-only, and only
at particular places modified. That way, it's easier to track who
changes a property.
Also, add a logging line with "ip-ifname" prefix.
Most implementations of realize_start_notify() do the same
for link_changed().
Let NMDevice's base implementation of realize_start_notify() call
link_changed() -- which by default does notthing. This allows subclasses
to only overwrite link_changed().
All implementations of link_changed() chain up to NMDevice's
base implementation. Thus, everybody wants to set the carrier.
Refactor the code to set the carrier outside of link_changed().
This makes it easier to install the files with proper names.
Also, it makes the makefile rules slightly simpler.
Lastly, the documentation is now generated into docs/api, which makes it
possible to get rid of the awkward relative file names in docbook.
Keep the include paths clean and separate. We use directories to group source
files together. That makes sense (I guess), but then we should use this
grouping also when including files. Thus require to #include files with their
path relative to "src/".
Also, we build various artifacts from the "src/" tree. Instead of having
individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be
unified. Previously, the CFLAGS for each artifact differ and are inconsistent
in which paths they add to the search path. Fix the inconsistency by just
don't add the paths at all.
When the device has an IP interface different from the main one, we
previously took the MTU saved in priv->mtu (which is the MTU initially
set on the underlying interface) and applied it to the IP interface.
This is wrong as it forces the two MTUs to be equal and breaks
connectivity for devices with encapsulation (as PPP). Instead, track
the two MTUs in different variables.
https://bugzilla.redhat.com/show_bug.cgi?id=1385198
It is a bit fragile not to clone the string because we depend on
nm_ip6_config_get_search(priv->ip6_config) to be stable.
In practice, it's no problem. Saves an additional strdup and the
effort to cleanup the memory afterwards.
- only record @now timestamp if we actually need it.
- use gint32 for @now. It seems wrong that NMNDiscDNSServer
uses guint32 for the timestamp. We keep
nm_utils_get_monotonic_timestamp_s() as gint32 for a reason.
- ensure the arrays are initialized to zero. E.g.
ndisc_addr->dad_counter was uninitalized.
- set the size for arrays outside the loop
- use g_array_unref(). I think that is usually better. It makes
only a difference when somebody else holds a reference to the
array. And in that case, it usually seems better not to clear
the array, just release your refrence.
There's two parts of the configuration involved: the subnet addresses
and the DNS information.
For the addressing, the shared (downlink) device signals the policy needs for a
/64 subnet. When it gets one, it merges it into the autoconf configuration and
forwards to the NDisc. When more prefixes are needed, the (uplink) device asks
the DHCP manager and eventually signals delegation (reception) of a prefix.
The NMDevice only provides the mechanism, the actual subnetting needs to
be done by the NMPolicy.
For the DNS configuration, the shared device just copies it from
whichever device the policy deems suitable.
