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.
(cherry picked from commit 9fff9f501a)
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.
(cherry picked from commit b0aaff86b6)
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.
* all getter/setter/describe, ... functions grouped according to properties
* sort the settings groups alphabetically
(cherry picked from commit 418733f2c1)
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)
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 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)
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
(cherry picked from commit 7dde8d8106)
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
(cherry picked from commit b85b8ed6fa)
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
The user can't do much about it and we can recover. This is a temporary
measure to avoid unnecessarily bothering the user.
(cherry picked from commit 7fec0755c9)
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.
(cherry picked from commit 4215c2640a)
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?).
(cherry picked from commit 6c96aafaa9)
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?).
As the fast-supported flag changes, update the existing supplicant
interfaces with the new information.
Also, by default assume it is supported.
(cherry picked from commit 872b9ec5ea)
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
(cherry picked from commit 66ff601ecf)
