A NMPClass that has data outside the plobj part, needs
to implement the cmd_obj_*() hooks, instead of cmd_plobj_*().
For those objects, reasoning only about the plobj part is not
sufficient. Implementing both hooks is also unnecessary and
confusing.
Ensure that if we have cmd_obj_*() hooks set, that the corresponding
cmd_plobj_*() hooks are unset.
The if-else-if was wrong. It meant that if an object did not implement
cmd_plobj_id_copy(), nothign was copied (for id-only).
I think this code path was not actually hit, because we never clone
an object only by ID.
Fixes: c91a4617a1 ('nmp-object: allow missing implementations for certain virtual functions')
In the commit 2a11c57c4e ('libnm/wifi: rework NMSetting8021xAuthFlags
to explicitly disable TLS version'), it said:
> In the future, supplicant may disable options by default, and
> the inverse option can become interesting to configure
> "tls_disable_tlsv1_0=0". When that happens, we can solve it by
> adding another flag NM_SETTING_802_1X_AUTH_FLAGS_TLS_1_0_ENABLE.
This commit adds the `NM_SETTING_802_1X_AUTH_FLAGS_TLS_1_0_ENABLE`
flag as well as similar flags for other TLS versions.
This commit also adds flags for TLS v1.3, as the corresponding flags
are now provided in wpa_supplicant.
The NMSetting8021xAuthFlags setting is rejected when both enable and
disable are set for the same TLS version. if-else-if is used in
nm_supplicant_config_add_setting_8021x to guarantee this behavior.
It prefers ENABLE over DISABLE to match the behavior of wpa_supplicant.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1133https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1450
Fix up the doc comment so that the gir data gets that right.
Fixes: 90d0ae0faf ('libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly')
- the static assertions were wrong, there was a "," instead of "==".
- the numeric values were wrong, as shown by the static assertions.
- move the code comment to the implementation. This does not seem
relevant for the library user and should not be in the public header.
Fixes: 08e845f651 ('nm-setting: mangle public constant to make g-ir-scanner happy')
Fix this compile error when "defined(__GNUC__) && (__GNUC__ > 2) &&
defined(__OPTIMIZE__)" doesn't match:
In file included from ../src/libnm-std-aux/nm-default-std.h:102,
from ../src/libnm-std-aux/nm-std-utils.c:3:
../src/libnm-std-aux/nm-std-aux.h: In function ‘NM_ALIGN_TO’:
../src/libnm-std-aux/nm-std-aux.h:160:6: error: expected expression before ‘{’ token
160 | ({ \
| ^
../src/libnm-std-aux/nm-std-aux.h:169:31: note: in expansion of macro ‘_NM_BOOLEAN_EXPR_IMPL’
169 | #define NM_BOOLEAN_EXPR(expr) _NM_BOOLEAN_EXPR_IMPL(NM_UNIQ, expr)
| ^~~~~~~~~~~~~~~~~~~~~
../src/libnm-std-aux/nm-std-aux.h:175:27: note: in expansion of macro ‘NM_BOOLEAN_EXPR’
175 | #define NM_LIKELY(expr) NM_BOOLEAN_EXPR(expr)
| ^~~~~~~~~~~~~~~
../src/libnm-std-aux/nm-std-aux.h:238:19: note: in expansion of macro ‘NM_LIKELY’
238 | } else if NM_LIKELY (cond) { \
| ^~~~~~~~~
../src/libnm-std-aux/nm-std-aux.h:449:5: note: in expansion of macro ‘nm_assert’
449 | nm_assert(nm_utils_is_power_of_two(ali));
| ^~~~~~~~~
The NM_LIKELY()/NM_UNLIKELY() macros should be alwas called enclosed
in parentheses like in:
if (NM_LIKELY(i == 1)) ...
and should be expanded with only a single pair of parentheses so that
expressions like (i = 1) generate a compiler warning.
Fixes: 030d68aef7 ('shared: add nm_assert() to "nm-std-aux.h"')
libnm-core-impl has lots of internal meta data about the properties.
In particular, which properties exist (their names), and their D-Bus
type.
We should use this information for our manual pages. For example,
currently `man nm-settings-dbus` has nonsense like: "Value Type: array
of string", when it should be reall "as".
In a first step, generate an XML with that meta data for later use.
This is the better name, becuse this is not in particular about "docs".
It's about generating an XML with the information from the settings
meta data for nmcli.
We will do something similar with the libnm-core meta data.
It just feels nicer to be explicit about the filenames and
not rely on a specific naming.
Also, in meson we can directly pass the target as argument, which
expands to the filename but also adds a dependency.
nm_setting_diff() ends up calling the compare_fcn() hook. Previously,
the hook for "dns" was _nm_setting_property_compare_fcn_default()
and the hook for "dns-data" was _nm_setting_property_compare_fcn_ignore().
That's wrong. _nm_setting_property_compare_fcn_default() converts
the property to D-Bus and compares the GVariant. However, "dns" has
to_dbus_only_in_manager_process set, so it wouldn't
Fixes: 63eaf168d1 ('libnm: add "dns-data" replacement for "ipv[46].dns" properties on D-Bus')
property_to_dbus() gets called for two reasons. Once from
_nm_setting_to_dbus(). In that case, we want to honor
to_dbus_only_in_manager_process().
It gets also called from _nm_setting_property_compare_fcn_default(),
with ignore_flags set. In that case, we don't want to ignore the property
as the hook really wants to compare them.
Fixes: c8392018ca ('libnm: refactor to-dbus on the client skipping to serialize legacy properties')
On rhel-8.7, we use a different gettext version, so the Makefile
looks different. Adjust patch the source.
Fixes: 7ee0da3eaf ('build: don't "update-po" during make dist')
It seems really ugly, to pass a callback function of wrong
signature. Granted, it probably works due to the C calling
convention, but it seems odd.
Use callbacks of the proper type instead. Then we also don'
need g_signal_connect_swapped().
While at it, rename. "connected_state_cb()" seems a bad name.
Otherwise, this file would need to be included in POTFILES.in.
This is unnecessary.
Fixes: 06cf1f5e2d ('platform/tests: extend monitor tool to dump the state of NMPlatform')
Unfortunately, for this we require SetLinkDNSEx() API from v246.
That adds extra complexity.
If the configuration contains no server name, we continue using
SetLinkDNS(). Otherwise, at first we try using SetLinkDNSEx().
We will notice if that method is unsupported, reconfigure with
SetLinkDNS(), and set a flag to not try that again.
- rename the "has_" variables to have the same name as the API that they
check.
- do an if-else-if for checking the operation when detecting support.
This just feels nicer. No strong reasons.
The DNS name can now also contain the DoT server name. It's not longer a
binary IP address only.
Extend NML3ConfigData to account for that. To track the additional
data, use the string representation. The alternative to have a separate
type that contains the parsed information would be cumbersome too.
Now, nm_setting_ip_config_add_dns() no longer asserts that
the name is a valid DNS nameserver. Instead, that is handled
by nm_connection_verify().
Also, the DNS property is going to be extended to support
specifying the SNI server name for DNS over TLS. The validation
would need to be extended.
Instead, drop the validation from nmcli. nmcli often needs to understand
what is happening. But in this case, it doesn't need to know (or
validate) the exact text. Don't duplicate the validation and let
libnm (or the daemon) reject invalid settings.
- nm_setting_ip_config_add_dns() and nm_setting_ip_config_remove_dns_by_value()
used to assert that the provided input is valid. That is not
documented and highly problematic.
Our parsing code for keyfile, ifcfg-rh and GVariant rightly just call
add. Likewise, nmcli. We cannot reasonably expect them to pre-validate
the input. Why would we anyway?
This is wrong in particular because we usually want the user to be
able to construct invalid settings. That is often necessary, because
whether a value is valid depends on other values. So in general, we
can only validate when all properties are set. We have
nm_connection_verify() for that, and asserting/validating during add
is very wrong. Note that "add" still filters out duplicates, which
may be an inconsistency, but well.
Also, the user could set any bogus value via the NM_SETTING_IP_CONFIG_DNS
property. Those should be allowed to be removed, and the same values
should be allowed to be added via the add method.
- add() does a normalization, presumably so that the values look nice.
Do the same normalization also when using the NM_SETTING_IP_CONFIG_DNS
property setter.
- previously, the setter could also set unnormalized values. As
nm_setting_ip_config_remove_dns_by_value() looked for the normalized
value, you couldn't remove such values anymore. That is fixed now,
by letting the property setter do the same normalization.
- don't allocate a GPtrArray unless we need it. No need for the extra
allocation.
- in the property setter, first set the new value before destroying the
previous GPtrArray. It might not be possible, but it's not clear to me
whether the strv argument from the GValue is always deep-copied or
whether it could contain strings to the DNS property itself.
It is almost always wrong, to split IPv4 and IPv6 behaviors at a high level.
Most of the code does something very similar. Combine the two functions.
and let them handle the difference closer to where it is.
On D-Bus, the properties "ipv[46].dns" are of type "au" and "aay",
respectively.
Btw, in particular "au" is bad, because we put there a big-endian
number. There is no D-Bus type to represent big endian numbers, so "u"
is bad because it can cause endianess problem when trying to remote
the D-Bus communication to another host (without explicitly
understanding which "u" properties need to swap for endinness).
Anyway. The plain addresses are not enough. We soon will also support
the DNS-over-TLS server name, or maybe a DoT port number. The previous
property was not extensible, so deprecate it and replace it by
"dns-data".
This one is just a list of strings. That is unlike "address-data" or
"route-data", which do a similar thing but are "a{sv}" dictionaries.
Here a string is supposed to be sufficient also for the future. Also,
because in nmcli and keyfile will will simply have a string format for
representing the extra data, not a structure (unlike for routes or
addresses).
The previous could would first check whether the new property is not
set. In almost all cases, the new property is actually set.
We can get away with fewer lookups, by checking for the expected things
first.
