fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-26 04:10:14 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/libnmc-setting
History
Íñigo Huguet 7ec363a79a ip6: revert to using sysctl ipv6.conf.default for ip6-privacy 
Commit 797f3cafee ('device: fall back to saved use_tempaddr value
instead of rereading /proc') changed the behaviour of how to get the
last resort default value for ip6-privacy property.

Previously we read it from /proc/sys/net/ipv6/conf/default, buf after
this commit we started to read /proc/sys/net/ipv6/conf/<iface> instead,
because the user might have set a different value specific for that device.
As NetworkManager changes that value on connection activation, we used
the value read at the time that NetworkManager was started.

Commit 6cb14ae6a6 ('device: introduce ipv6.temp-valid-lifetime and
ipv6.temp-preferred-lifetime properties') introduced 2 new IPv6 privacy
related properties relying on the same mechanism.

However, this new behaviour is problematic because it's not predictable
nor reliable:
- NetworkManager is normally started at boot time. That means that, if a
  user wants to set a new value to /proc/sys/net/ipv6/conf/<iface>,
  NetworkManager is likely alread running, so the change won't take
  effect.
- If NetworkManager is restarted it will read the value again, but this
  value can be the one set by NetworkManager itself in the last
  activation. This means that different values can be used as default in
  the same system boot depending on the restarts of NetworkManager.

Moreover, this weird situation might happen:
- Connection A with ip6-privacy=2 is activated
- NetworkManager is stopped. The value in
  /proc/sys/net/ipv6/conf/<iface>/use_tempaddr remains as 2.
- NetworkManager starts. It reads from /proc/sys/... and saves the value
  '2' as the default.
- Connection B with no ip6-privacy setting is activated. The '2' saved
  as default value is used. The connection didn't specify any value for
  it, and the value '2' was set by another connection for that specific
  connection only, not manually by a user that wanted '2' to be the
  default.

A user shouldn't have to think on when NetworkManager starts or restarts
to known in an easy and predictable way what the default value for
certain property is. It's totally counterintuitive.

Revert back to the old behaviour of reading from
/proc/sys/net/ipv6/conf/default. Although this value is used by the
kernel only for newly created interfaces, and not for already existing
ones, it is reasonable to think on these settings as "systemwide
defaults" that the user has chosen.

Note that setting a different default in NetworkManager.conf still takes
precedence.
2024-05-10 12:01:08 +00:00
..
tests libnm-client: Add public nm_conn_wireguard_import() func 2022-07-21 14:53:26 +02:00
meson.build meson: remove deprecated ExternalProgram.path 2024-04-04 08:13:38 +00:00
nm-meta-setting-access.c all: use nm_g_array_{index,first,last,index_p}() instead of g_array_index() 2022-09-15 12:39:07 +02:00
nm-meta-setting-access.h format: reformat source tree with clang-format 13.0 2021-11-29 09:31:09 +00:00
nm-meta-setting-base-impl.c HSR: add support to HSR/PRP interface 2023-12-05 08:05:56 +01:00
nm-meta-setting-base-impl.h HSR: add support to HSR/PRP interface 2023-12-05 08:05:56 +01:00
nm-meta-setting-base.h build: move "clients/common/" to "src/libnmc-{base,setting}/" 2021-03-02 08:38:25 +01:00
nm-meta-setting-desc.c ip6: revert to using sysctl ipv6.conf.default for ip6-privacy 2024-05-10 12:01:08 +00:00
nm-meta-setting-desc.h all: differentiate NM_CLONED_MAC_IS_SPECIAL() for wired/wireless 2023-11-16 13:07:53 +01:00
README.md all: add some README.md files describing the purpose of our sources 2021-08-19 17:51:11 +02:00
settings-docs.h.in ip6: revert to using sysctl ipv6.conf.default for ip6-privacy 2024-05-10 12:01:08 +00:00

README.md

libnmc-setting

A client library on top of libnm (and libnm-base). Like libnmc-base, this is a helper library that a libnm client could use.

But its purpose is more specific. It's mainly about providing a generic API for handling connection properties. As such, it's only used by nmcli and in practice also specific to nmcli.

Theoretically, the API is supposed to be generic, so we could imagine another client that uses this beside nmcli.

Like libnm-base, this has a similar purpose and application as ../libnm-client-aux-extern/, the difference is that it's even more specific.