1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
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 `GObject`s 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](../../introspection/org.freedesktop.NetworkManager.IP4Config.xml)
(and [for IPv6](../../introspection/org.freedesktop.NetworkManager.IP6Config.xml)).
`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]Config`s, 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.
|
