fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-02-27 22:10:40 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/core/README.next.ip-config.md
Thomas Haller 58287cbcc0 core: rework IP configuration in NetworkManager using layer 3 configuration 
Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3
manager for the IP configuration of an interface. Use NML3ConfigData as
pieces of configuration that the various components collect and
configure. NMDevice is managing most of the IP configuration at a higher
level, that is, it starts DHCP and other IP methods. Rework the state
handling there.

This is a huge rework of how NetworkManager daemon handles IP
configuration. Some fallout is to be expected.

It appears the patch deletes many lines of code. That is not accurate, because
you also have to count the files `src/core/nm-l3*`, which were unused previously.

Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-11-18 16:21:29 +01:00

3.5 KiB
Raw Permalink Blame History

Rework NMIP[46]Config for next branch

The next branch is a large rework of internals, how IP configuration is done by NMDevice.

Previously, there are two GObjects named NMIP4Config and NMIP6Config. These serve different purposes:

  1. They are data containers that can track IP configuration. As such, NMDevice and various parts (like NMDhcpClient) create them, pass them around and mutate/merge them to track the IP configuration.

  2. They are also subclasses of NMDBusObject and exported on D-Bus as /org/freedesktop/NetworkManager/IP4Config/1, etc. As such, see their D-Bus API (and for IPv6).

next branch will replace use 1) with NML3ConfigData. NML3ConfigData are immutable (sealable) data containers with little logic. This leaves NMIP4Config to only implement 2).

This needs to be reworked.

  • Now NMIP4Config and NMIP6Config are subclasses of NMIPConfig. The goal is to treat IPv4/IPv6 similar and generically. Probably there should be very little code in the subclasses left and most should move to the parent classes. We still need separate GObject types though, because that is how NMDBusObject's glue code can handle different D-Bus paths.

  • Now NML3Cfg is a handle for the IP configuration parameters of a device (ifindex). As NMIPConfig mostly is about exporting the current IP configuration, it probably can get most of it from there (and by listening to signals to that).

  • Note that NMDevice, NMActiveConnection refer NMIP[46]Configs, and most importantly, the respective D-Bus objects refer to them. As NMVpnConnection (and "org.freedesktop.NetworkManager.VPN.Connection" interface) are modeled as "subclasses" of NMActiveConnection, they also have one. That means, it's not entirely clear what these properties even are. For example, currently, NMDevice does a (terrible) dance of tracking external NMIP[46]Config objects, merging, intersecting and subtracting them with other NMIP4Config objects to get the merged one, which is then exported on D-Bus. That merged object does therefore not directly expose the IP addresses that are actually configured on the interface (ip addr), but more what NetworkManager wanted to configure and the (terrible) feedback loop where the platform addresses get synced. With next branch and NML3Cfg there is a clear distinction between what NetworkManager wants to configure vs. what is actually configured. I think for NMDevice and NMActiveConnection, the IP addresses on "org.freedesktop.NetworkManager.IP4Config" should expose the IP addresses that are actually in platform (ip addr). If there is a need to expose additional information (like things that NetworkManager wanted to configure), then this should be different/new API. On the other hand, currently NMVpnConnection's NMIP4Config only tracks the IP addresses that come from the VPN plugin. So it's much more what it wants to configure (from the VPN plugin), and not at all about what is configured on the interface. I think that needs to change. A NMIPConfig object on D-Bus exposes IP configuration information about an netdev interface. Period. That also means that a NMVpnConnection (which currently is like a active connection associated with the device) links to the same NMIPConfig object as the underlying device.