This code is not specific to "nm-ip4-config.h"/"nm-ip6-config.h".
It applies to everybody who wants to iterate over a dedup-multi-index of
certain NMPObjects. Move it.
They ensure to consistently return -1, 0, 1. Also, I think they are
easier to understand.
What is in general hard to understand, whether a comparison sorts
ascending or descending. The macros maybe make that easier too, but it's
still confusing. That's why we have a test.
First of all, the entire nm_device_generate_connection() and
nm_ip._config_create_setting() approach is fundamentally flawed. You
cannot generate sensible configuration by reading IP addresses from
an interface. Anyway, that's what we still sometimes do, and we possibly
should do it less and less.
It's ugly that nm_ip6_config_capture() would read the "disable_ipv6"
sysctl value and cache it in NMIP6Config. Only so that it can be use
much later during nm_ip6_config_create_setting().
Instead, read the sysctl value shortly before it's needed.
This is not in "nm-glib.h", because it's not a complete replacement.
In glib before 2.62, it's not possible to implement g_ptr_array_copy()
as glib provides it, because the element_free_func is not accessible.
So, instead add our own implemented, which follows glib's version as
much as it can.
If IPv6 is disabled, changing the IPv6 MTU fails and NM complains with
a warning. Since this error is expected and doesn't do any harm,
downgrade the logging level to DEBUG.
Since IPv6 kernel support can be built as a module, we have to check
the existence of /proc/sys/net/ipv6 every time. Instead of checking it
and then setting the MTU (adding one /proc access for everyone), just try
to set the MTU; in case of failure, determine the reason for the error.
https://bugzilla.redhat.com/show_bug.cgi?id=1840989https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/585
Currently NMIP4Config and NMIP6Config both track the data to be
configured, they expose properties on D-Bus, and they have logic for
capturing and applying settings to platform.
We will split that.
- NMIP4Config and NMIP6Config will expose data on D-Bus.
- NML3Cfg will have the logic for handling IP configuration.
- NML3ConfigData will track data to be configured.
NML3ConfigData mirrors NMIP4Config/NMIP6Config in many aspects. For now,
this duplicates a lot of code. More will be done later. Eventually,
NMIP4Config/NMIP6Config will drop the duplicated functionality.
The NML3Cfg instance tracks and prepares the IP configuration.
However, that is also partly exposed on other objects, like
NMIP4Config's "route-data" property.
Add an API, so that NMIP4Config can register itself to be notified
when something relevant changes.
This is an alternative to standard GObject properties and signals. They
often seem more effort than worth. That is, because in this case,
NMIP4Config.route-data has no other task then to re-emit the signal.
So, to implement that with GObject properties/signals, we would have to
add a property/signal to NML3Cfg, subscribe to it from NMIP4Config,
and remit the signal. An alternative is to bind properties, but that
would still be quite some extra code, and unclear that it would be
simpler. Not to mention the overhead, as bindings are themself full
GObject instances, that register to and emit signals by name.
We have several fields in the header file, so that the frequently used accessors
can be inlined. However, we also want some private data. Add a structure for that.
We need to react to platform changes. Also, we usually want to delay the
reaction to an idle handler.
Instead of subscribing each NML3Cfg instance itself to platform changes,
let only NMNetns do that. The goal is of course that each platform event
only needs to notify the NML3Cfg instance, which collects the events and
schedules them on the idle handler.
_ip_iface_update() only had one caller. The code is simpler to
understand by inlining it.
Also, it is relevant where and how we set ip_iface_ and ip_ifindex_
fields. Keep the places few and easily understandable.
and rename to nm_utils_ip_route_attribute_to_platform(). The function is independent
from NMIP4Config. We also will use it outside of NMIP4Config. Also, "NetworkManagerUtils.c"
already has similar functions that parse libnm structures to internal structures.
_nm_ip_config_best_default_route_set() doesn't really do anything
special. Use the generic helper function for the same job.
Also because NMIP4Config in the current form will be replaced by
something else, and this code needs to change.
This is of course trivial. However, we use this macro at several places
as and index into an array of length 2, to lookup either the IPv4 or
IPv6 element. As such, this MUST return 0 or 1. This promise is what the
macro should convey.
nm_gobject_notify_together() is supposed to emit one or more property changed
notifications, but with freezing (and thawing) the notifications.
Also, we want to allow the user to pass PROP_0, for skipping emitions.
The point is code like
nm_gobject_notify_together (obj,
PROP_FOO,
bar_changed ? PROP_BAR : PROP_0);
Optimize the code to only freeze/thaw the notifications, if we are
actually notifying more than one properties.
The 'clsact' qdisc is similar to 'ingress' but supports both ingress
and egress [1]. It uses the same handle as 'ingress' and has two child
classes :fff2 (ingress) and :fff3 (egress) on which filters can be
attached.
With clsact, for example, it becomes possible to do port mirroring
with a single qdisc:
nmcli connection modify mirror +tc.qdisc "clsact"
nmcli connection modify mirror +tc.tfilter
"parent ffff:fff3 matchall action mirred egress mirror dev dummy1"
nmcli connection modify mirror +tc.tfilter
"parent ffff:fff2 matchall action mirred egress mirror dev dummy1"
instead of two (ingress + i.e. prio). We don't support yet the
symbolic names 'ingress' and 'egress' for :fff2 and :fff3 in the
filter.
See-also: https://bugzilla.redhat.com/show_bug.cgi?id=1436535
[1] https://lwn.net/Articles/671458/
Currently, we would not mark non-unicast routes with their type, so they
would wrongly appear as unicast routes in the D-Bus API.
That is wrong. For now, just hide them.
Fixes: 5d0d13f570 ('platform: add support for local routes')
A connection that fails due to dependency-failed is not able to
reconnect until the master connection activates again; when this
happens, the master clears the blocked reason for all its slaves in
activate_slave_connections() and tries to reconnect them. For this to
work, the slave should be marked as blocked when it fails with
dependency-failed.
If the device state change (to disconnected or unmanaged) triggered by
a sleep event happens after the wake, the devices becomes wrongly
unmanaged and it's necessary to manually manage it again, or restart
NM.
During the wake event we should disconnect the device_sleep_cb()
callback for all devices because we don't want to react to state
changes anymore; in particular we don't need to detect when the device
becomes disconnected to unmanage it.
If the list of addresses, routes and rules is empty, we still want to mangle
the applied connection, to also have an empty list.
nm-cloud-setup has certain expectations. For example, that the static addresses,
routes and rules of the active connection is entirely under the control of the
tool. For example, so it usually replaces the lists entirely. It also should do
that, if the new list is empty.
Maybe, one day there could be more complex merging strategies, where the user could
also add static addresses, routes, or rules to the profile, and nm-cloud-setup
would preserve them. However, that is not implemented, nor is it clear how exactly
that would work.
