mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-02-17 06:40:37 +01:00

History

Thomas Haller 56d0d35516 mptcp: rework "connection.mptcp-flags" for enabling MPTCP 1) The "enabled-on-global-iface" flag was odd. Instead, have only and "enabled" flag and skip (by default) endpoints on interface that have no default route. With the new flag "also-without-default-route", this can be overruled. So previous "enabled-on-global-default" now is the same as "enabled", and "enabled" from before behaves now like "enabled,also-without-default-route". 2) What was also odd, as that the fallback default value for the flags depends on "/proc/sys/net/mptcp/enabled". There was not one fixed fallback default, instead the used fallback value was either "enabled-on-global-iface,subflow" or "disabled". Usually that is not a problem (e.g. the default value for "ipv6.ip6-privacy" also depends on use_tempaddr sysctl). In this case it is a problem, because the mptcp-flags (for better or worse) encode different things at the same time. Consider that the mptcp-flags can also have their default configured in "NetworkManager.conf", a user who wants to switch the address flags could previously do: [connection.mptcp] connection.mptcp-flags=0x32 # enabled-on-global-iface,signal,subflow but then the global toggle "/proc/sys/net/mptcp/enabled" was no longer honored. That means, MPTCP handling was always on, even if the sysctl was disabled. Now, "enabled" means that it's only enabled if the sysctl is enabled too. Now the user could write to "NetworkManager.conf" [connection.mptcp] connection.mptcp-flags=0x32 # enabled,signal,subflow and MPTCP handling would still be disabled unless the sysctl is enabled. There is now also a new flag "also-without-sysctl", so if you want to really enable MPTCP handling regardless of the sysctl, you can. The point of that might be, that we still can configure endpoints, even if kernel won't do anything with them. Then you could just flip the sysctl, and it would start working (as NetworkManager configured the endpoints already). Fixes: `eb083eece5` ('all: add NMMptcpFlags and connection.mptcp-flags property') (cherry picked from commit `c00873e08f`)		2022-08-25 23:12:53 +02:00
..
meson.build	build/meson: cleanup dependencies for libnm-core-aux-intern	2021-02-28 10:42:05 +01:00
nm-auth-subject.c	format: reformat source tree with clang-format 13.0	2021-11-29 09:31:09 +00:00
nm-auth-subject.h	build: move "libnm-core/" to "src/" and split it	2021-02-18 19:46:51 +01:00
nm-common-macros.h	build: move "libnm-core/" to "src/" and split it	2021-02-18 19:46:51 +01:00
nm-libnm-core-utils.c	mptcp: rework "connection.mptcp-flags" for enabling MPTCP	2022-08-25 23:12:53 +02:00
nm-libnm-core-utils.h	mptcp: rework "connection.mptcp-flags" for enabling MPTCP	2022-08-25 23:12:53 +02:00
README.md	build: move "libnm-core/" to "src/" and split it	2021-02-18 19:46:51 +01:00

README.md

libnm-core-aux-intern

libnm-core-aux-intern is a static library that:

uses parts of libnm-core-impl, that are public API of libnm (i.e. libnm-core-public).
that is statically linked into libnm-core-impl (and thus libnm and NetworkManager core.
that can also be statically linked into other users of libnm.

Basically, it is a static library with utility functions that extends libnm-core-impl (the part that is public API of libnm), but it is also used by libnm-core-impl itself.

That means:

you can use it everywhere where you either statically link with libnm-core-impl, or dynamically link with libnm.
you can even use it inside of libnm-core-impl itself. This is the difference between libnm-core-aux-intern and libnm-core-aux-extern.

Note that libnm-core-aux-intern only uses public API of libnm.

This directory should not be added to the include search path. Instead, users should fully qualify the include like #include "libnm-core-aux-intern/nm-auth-subject.h".