The active connection has an immutable connection property, but is
cleaned asynchronously by the manager after its settings connection is
done. Fine, let's remove it from the bus first though, so that we don't
hang there with a dangling object path.
When searching for "*", we still need to check for higher priority
"except:" matches. But don't duplicate the search loop and just
proceed with the regular searched.
It already has the "if (!except && match == NM_MATCH_SPEC_MATCH)" which
short-cuts the search.
Instead of passing on invdividual arguments for the match, create
a MatchDeviceData structure and pass it on.
This reduces the number of arguments and extending it later should
be easier. Also, lazily parse the hardware address as needed.
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.
After commit 22e8af6242 ("device: set a per-device default MTU on
activation") we explicitly set the VLAN MTU to 1500 if not overridden
by user settings. This has the advantage that the MTU is set to a
predictable value, while before it could have different values
depending on when the interface was created (for example, the
interface would get a 1500 MTU if created during boot, or would
inherit the parent's MTU if activated manually).
However, a better default value is the MTU of the parent interface
which is in most cases what the user wants. This value was the default
before commit 22e8af6242 for manually activated connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1414186
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().
Since commit "c920909 contrib/rpm: put translations in
NetworkManager-libnm and NetworkManager-glib packages", both
subpackages install the same translation files without a direct
dependency between the two packages. Thus, if a user tries
to update only one of the two subpackages, it will fail
during the installation due to conflicting files.
Fix that by having the subpackages conflict (per version).
This way, the conflict is detected before starting the
installation.
https://bugzilla.redhat.com/show_bug.cgi?id=1406454
We start to track changes to the device's properties only after the
active connection gets activated. It's wrong to return properties
while we don't track their changes as this causes stale objects
references on D-Bus. Let's return DHCP and IP configurations from the
device only when the connection is activated.
At some point gobject-introspection added an API to add a library path
and stopped honoring the LD_LIBRARY_PATH (a bug, according to GI
documentation?).
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 ()) {
^
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.
