diff options
author | Thomas Haller <thaller@redhat.com> | 2022-09-08 13:06:13 +0200 |
---|---|---|
committer | Thomas Haller <thaller@redhat.com> | 2022-09-08 17:35:04 +0200 |
commit | 3272e5cc92bd5b3f4c1800d971c369d67c18f1f1 (patch) | |
tree | a026ab2d859cf028404f63588ab997e000f5e2fd | |
parent | bdaba47a68ea82cd112383ce6d354cfe95e91664 (diff) | |
download | NetworkManager-3272e5cc92bd5b3f4c1800d971c369d67c18f1f1.tar.gz |
libnm: avoid serializing "ipv6.addr-gen-mode" default to D-Bus
When serializing setting properties to GVariant/D-Bus, we usually
omit values that are set to the default. That is done by libnm(-core),
so it happens both on the daemon and client side. That might be
useful to avoid a large number of properties on D-Bus.
Before changing the default value for "ipv6.addr-gen-mode" ([1]), we
would not serialize the previous default value ("stable-privacy").
Now we would serialize the new default value ("default). This change
causes problems.
Scenario 1: have a profile in the daemon with "ipv6.addr-gen-mode=stable-privacy",
have an older daemon version before [1] and a newer client after [1]. Result:
The daemon exposes the profile on D-Bus without the addr-gen-mode
field (because it's the default). To the client, that is interpreted
differently, as "ipv6.addr-gen-mode=default". This is already somewhat
a problem.
More severe is when modifying the profile, the client would now serialize
the value "default" on D-Bus, which the older daemon rejects as invalid.
That means, you could not modify the profile, unless also resetting
addr-gen-mode to "stable-privacy" or "eui64".
You can imagine other scenarios where either the daemon or the client is
before/after change [1] and the addr-gen-mode is set to either "default"
or "stable-privacy". Depending on what scenario you look, that can either be
good or bad.
Scenario 1 is pretty bad, because it means `dnf upgrade NetworkManager
&& nmcli connection modify ...` will fail (if the daemon was not
restated). So try to fix Scenario 1, by also not serializing the new
default value on D-Bus. Of course, some of the scenarios will get
different problems, by exacerbating one side misunderstanding the actually
set value and interpreting a missing value on D-Bus wrongly. But those
problems are likely less severe.
In case both client and daemon are older/newer than [1], it doesn't
matter either way. The problem happens with different version and is
caused by a change of the default value.
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/e6a33c04ebe1ac84e31628911e25bdfd7534dd3c
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1372
(cherry picked from commit 70060d570b4b35e029a5d6ab8aa8026563ad580c)
-rw-r--r-- | src/libnm-core-impl/nm-setting-ip6-config.c | 3 |
1 files changed, 1 insertions, 2 deletions
diff --git a/src/libnm-core-impl/nm-setting-ip6-config.c b/src/libnm-core-impl/nm-setting-ip6-config.c index 8b593b9733..94794d1e14 100644 --- a/src/libnm-core-impl/nm-setting-ip6-config.c +++ b/src/libnm-core-impl/nm-setting-ip6-config.c @@ -832,8 +832,7 @@ nm_setting_ip6_config_class_init(NMSettingIP6ConfigClass *klass) NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_DEFAULT, NM_SETTING_PARAM_NONE, NMSettingIP6ConfigPrivate, - addr_gen_mode, - .to_dbus_including_default = TRUE); + addr_gen_mode); /** * NMSettingIP6Config:token: |