This ABI was backported all the way to 1.42.8 and 1.40.20 and to rhel-8.9.
Move the ABI to a separate symbol version, which we have in all those
versions.
Add per port priority support for bond active port re-selection during
failover. A higher number means a higher priority in selection. The
primary port still has the highest priority. This option is only
compatible with active-backup, balance-tlb and balance-alb modes.
The symbol "nm_active_connection_get_controller" was backported to
1.42.1+. Since 1.44 is not yet released, move the symbol from
libnm_1_44 to libnm_1_42_2, like it is on 1.42.2 release. That way, we
don't need to duplicate the symbol while 1.44 being forward compatible
with 1.42.2.
NM 1.44 is not released yet and 1.42.2 will happen before 1.44.0, so we
can introduce the new API with version libnm_1_42_2 in both releases
without having duplicate symbols on 1.44.
This setting allows the user to remove the local route rule that is
autogenerated for both IPv4 and IPv6. By default, NetworkManager won't
touch the local route rule.
The configure flag and APN for the initial EPS bearer are used when
bringing up cellular modem connections. These settings are only relevant
for LTE modems.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
With LIBNM_CLIENT_DEBUG we get debug logging for libnm, either to stdout
or to stderr.
"test-client.py" runs nmcli as a unit test. It thereby catches stdout
and stderr. That means, LIBNM_CLIENT_DEBUG would break the tests.
Now honor the LIBNM_CLIENT_DEBUG_FILE environment variable to specify a
file to which the debug logs get written. The pattern "%p" is replaced
by the process id.
As before, nm_utils_print(0, ...) also honors this environment variable
and uses the same logging destination.
We silently tolerate NetworkManager not responding at all (easily
reproduced with e.g. pkill -STOP NetworkManager):
$ LIBNM_CLIENT_DEBUG=trace nmcli c show dummy666
libnm-dbus[23540]: <debug> [3316.81989] nmclient[ddafb84b8deebe4a]: new NMClient instance
libnm-dbus[23540]: <debug> [3316.81998] nmclient[ddafb84b8deebe4a]: starting async initialization...
libnm-dbus[23540]: <debug> [3316.82461] nmclient[ddafb84b8deebe4a]: name owner changed: (null) -> ":1.2"
libnm-dbus[23540]: <debug> [3316.82464] nmclient[ddafb84b8deebe4a]: fetch all
libnm-dbus[23540]: <debug> [3341.85715] nmclient[ddafb84b8deebe4a]: GetManagedObjects() call failed: Timeout was reached
libnm-dbus[23540]: <debug> [3341.85740] nmclient[ddafb84b8deebe4a]: async init complete with success
Error: dummy666 - no such connection profile.
libnm-dbus[23540]: <debug> [3341.86723] nmclient[ddafb84b8deebe4a]: release all
libnm-dbus[23540]: <debug> [3341.86798] nmclient[ddafb84b8deebe4a]: disposed
$
As a comment in _dbus_get_managed_objects_cb() explains, this is sort of
intentional. NetworkManager might just be shutting down and the libnm
users will eventually see the objects once a new daemon starts up.
This may make some sense for long-running clients ("nmcli monitor",
various desktop environments), but not for one-shot invocations that
require the daemon running, such as those of "nmcli c ...".
Let's not consider the client running unless we actually got the manager
object. That way the error message will make more sense:
$ LIBNM_CLIENT_DEBUG=trace nmcli c show dummy666
libnm-dbus[24730]: <debug> [5360.95480] nmclient[8cb898d3c891e210]: new NMClient instance
libnm-dbus[24730]: <debug> [5360.95487] nmclient[8cb898d3c891e210]: starting async initialization...
libnm-dbus[24730]: <debug> [5360.95901] nmclient[8cb898d3c891e210]: name owner changed: (null) -> ":1.2"
libnm-dbus[24730]: <debug> [5360.95904] nmclient[8cb898d3c891e210]: fetch all
libnm-dbus[24730]: <debug> [5385.98487] nmclient[8cb898d3c891e210]: GetManagedObjects() call failed: Timeout was reached
libnm-dbus[24730]: <debug> [5385.98497] nmclient[8cb898d3c891e210]: async init complete with success
Error: NetworkManager is not running.
libnm-dbus[24730]: <debug> [5385.98571] nmclient[8cb898d3c891e210]: release all
libnm-dbus[24730]: <debug> [5385.98698] nmclient[8cb898d3c891e210]: disposed
$
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1502
The current implementation of libnm guarantees that "o" and "ao"
properties are cleared when the device object goes away, i.e. when all
its interfaces disappear from the bus.
The "manager:device-removed" signal is emitted just before the device
is unexported, and usually properties are not cleared at that
time. So, the assertions about empty available connections and active
connection during "device-removed" seem wrong; remove them.
Whether the test passes or not depends on a race condition in the way
the mock NM service is stopped: we first close the pipe to the process
to force a clean shutdown (where all objects are orderly unexported)
but just after that we send SIGTERM which causes the service to drop
from the bus.
If libnm sees the service dropping from the bus, it deletes all
objects (thus clearing properties) and then emits
"device-removed"; in this case the test passes.
However in case of a clean shutdown, NM first emits the
"device-removed" signal and then unexports devices, leading to a
failure.
Fixes: aaa9a9cd25 ('libnm/client: don't reset properties when interface goes away')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1486
The types NMBridgeVlan, NMIPRoutingRule, NMRange, NMWireGuardPeer
are immutable (or immutable, after the seal() function is called).
Immutable types are great, as it means a reference to them can be shared
without doing a full clone. Hence the G_DEFINE_BOXED_TYPE() for these
types prefers to take a reference instead of cloning the objects. Except
for sealable types, where it will prefer to clone unsealed values.
Likewise, nm_simple_connection_new_clone() probably will just take
another reference to the value, instead of doing a deep clone.
libnm is not a thread-safe library in the sense that you could pass a
NMConnection or NMClient instance to multiple threads and access them
without your own synchronization. However, it should be possible that
multiple threads access (seemingly) distinct objects.
As the copy function of these boxed types (and nm_simple_connection_new_clone()
and similar) prefers to share the references to immutable types, it is important
that the ref function is thread-safe too. Otherwise you cannot just clone a
NMConnection on thread1, hand the clone to thread2 and operate on the
clone and the original independently. If you do before this patch, you would
hit a subtle race condition.
Avoid that. While atomic operations have a runtime overhead, being safe
is more important. Also, we already save a full malloc()/free() by
having immutable, ref-counted types. We just need to make it safe to use
in order to fully benefit from it.
G_TYPE_CHECK_INSTANCE_CAST() can trigger a "-Wcast-align":
src/core/devices/nm-device-macvlan.c: In function 'parent_changed_notify':
/usr/include/glib-2.0/gobject/gtype.h:2421:42: error: cast increases required alignment of target type [-Werror=cast-align]
2421 | # define _G_TYPE_CIC(ip, gt, ct) ((ct*) ip)
| ^
/usr/include/glib-2.0/gobject/gtype.h:501:66: note: in expansion of macro '_G_TYPE_CIC'
501 | #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type) (_G_TYPE_CIC ((instance), (g_type), c_type))
| ^~~~~~~~~~~
src/core/devices/nm-device-macvlan.h:13:6: note: in expansion of macro 'G_TYPE_CHECK_INSTANCE_CAST'
13 | (G_TYPE_CHECK_INSTANCE_CAST((obj), NM_TYPE_DEVICE_MACVLAN, NMDeviceMacvlan))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Avoid that by using _NM_G_TYPE_CHECK_INSTANCE_CAST().
This can only be done for our internal usages. The public headers
of libnm are not changed.
Reapply() is supposed to make sure that the system (the interface)
is configured as indicated by the applied-connection. That means,
it will remove/add configuration to make the system match the requested
configuration.
Add a flag "preserve-external-ip" which relaxes this. During reapply,
IP addresses/routes that exist on the interface and which are not known
(or added) by NetworkManager will be left alone.
This will be used by nm-cloud-setup, so that it can reconfigure the
interface in a less destructive way, which does not conflict with
external `ip addr/route` calls.
Note that the previous commit just adds "VersionInfo" and the
possibility to expose capabilities (patch-level). This is not used
for the new reapply flag, because, while we might backport the
reapply flag, we won't backport the "VersionInfo" property. Exposing
new capabilities via the "VersionInfo" property will only become useful
in the future, where we can backport a capability to older NM versions
(but those that have "VersionInfo" too).
This exposes NM_VERSION as number (contrary to the "Version", which is a
string). That is in particular useful, because the number can be
compared with <> due to the encoding of the version.
While at it, don't make it a single number. Expose an array of numbers,
where the following numbers are a bitfield of capabilities.
Note that before commit 3c67a1ec5e ('cli: remove version check against
NM'), we used to parse the "Version" string to detect the version. As
such, the information that "VersionInfo" exposes now, was already
(somewhat) available, you just had to parse the string. The main benefit of
"VersionInfo" is that it can expose capabilities (patched behavior) in
in a lightweight bitfield. To include the numerical version there is
just useful on top.
Currently no additional capabilities are exposed. The idea is of course
to have a place in the future, where we can expose additional
capabilities. Adding a capability flag is most useful for behavior that we
backport to older branches. Otherwise, we could just check the daemon version
alone. But since we only add "VersionInfo" property only now, we cannot backport
any capability further than this, because the "VersionInfo" property itself
won't be backported. As such, this will only be useful in the future by having
a place where we can add (and backport) capabilities.
Note that there is some overlap with the existing "Capability" property
and NMCapability enum. The difference is that adding a capability via "VersionInfo"
is only one bit, and thus cheaper. Most importantly, having it cheaper means
the downsides of adding a capability flag is significantly removed. In
practice, we could live without capabilities for a long time, so they
must be very cheap for them to be worth to add. Another difference might be,
that we will want that the VersionInfo is about compile time defaults (e.g.
a certain patch/behavior that is in or not), while NM_CAPABILITY_TEAM depends on
whether the team plugin is loaded at runtime.
Introduce a "vlan.protocol" property that specifies the protocol of a
VLAN, which controls the tag (EtherType) used for encapsulation.
Regular VLANs use 802.1Q (tag 0x8100). To implement VLAN stacking it's
sometimes useful to have 802.1ad VLANs with tag 0x88A8.
The property is a string instead of e.g. an enum because this allows
maximum flexibility in the future. For example, it becomes possible to
specify an arbitrary number in case if the kernel ever allows it.
The warning "-Wcast-align=strict" seems useful and will be enabled
next. Fix places that currently cause the warning by using the
new macro NM_CAST_ALIGN(). This macro also nm_assert()s that the alignment
is correct.
Add a new "ovs-port.trunks" property that indicates which VLANs are
trunked by the port.
At ovsdb level the property is just an array of integers; on the
command line, ovs-vsctl accepts ranges and expands them.
In NetworkManager the ovs-port setting stores the trunks directly as a
list of ranges.
The next commit is going to introduce a new object in libnm to
represent a range of ovs-port VLANs. A "range of integers" object
seems something that can be used for other purposes in the future, so
instead of adding an object specific for this case
(e.g. NMOvsPortVlanRange), introduce a generic NMRange object that
generically represents a range of non-negative integers.
Support managing the loopback interface through NM as the users want to
set the proper mtu for loopback interface when forwarding the packets.
Additionally, the IP addresses, DNS, route and routing rules are also
allowed to configure for the loopback connection profiles.
https://bugzilla.redhat.com/show_bug.cgi?id=2060905
This is the version shipped in Fedora 37. As Fedora 37 is now out, the
core developers switch to it. Our gitlab-ci will also use that as base
image for the check-{patch.tree} tests and to generate the pages. There
is a need that everybody agrees on which clang-format version to use,
and that version should be the one of the currently used Fedora release.
Also update the used Fedora image in "contrib/scripts/nm-code-format-container.sh"
script.
The gitlab-ci still needs update in the following commit. The change
in isolation will break the "check-tree" test.
Most users included this by accident, by including nm-connection.h. That
is not too great, becuase stuff it contains is by no means specific to
NMConnection.
Anyways, it's not like it would matter too that. I mainly care about it
being included in NetworkManager.h, so that there's one less special
case in a test that makes sure useful stuff from NetworkManager.h ends up
in gtk-doc (a separate commit).
libnm-core-impl/nm-setting-bond.c:1276: warning: Symbol name not found at the start of the comment block.
libnm-core-impl/nm-setting-vpn.c:1135: warning: Symbol name not found at the start of the comment block.
libnm-core-impl/nm-setting-vpn.c:1158: warning: Symbol name not found at the start of the comment block.
libnm-core-impl/nm-setting-wired.c:1560: warning: Symbol name not found at the start of the comment block.
libnm-client-impl/nm-dhcp-config.c:149: warning: Symbol name not found at the start of the comment block.
libnm-client-impl/nm-secret-agent-old.c:967: warning: Symbol name not found at the start of the comment block.
libnm-client-impl/nm-secret-agent-old.c:1010: warning: Symbol name not found at the start of the comment block.
libnm-client-impl/nm-secret-agent-old.c:1037: warning: Symbol name not found at the start of the comment block.
We got a typedef of the same name, and that causes gtk-doc to generate
invalid docbook and complain aloud:
../xml/nm-client.xml:4118: element refsect2: validity error : ID NMDnsEntry already defined
<refsect2 id="NMDnsEntry" role="typedef" condition="since:1.6">
Warning: multiple "IDs" for constraint linkend: NMDnsEntry.
In case the D-Bus interfaces start dropping off (typically all off them go
one by one when the object is being deleted), don't reset all the properties.
In particular, keep most properties around, only tear down "o" and "ao",
so that the object dependencies get torn down, but we still get enough
properties around to identify what the dead object was its heyday.
One example of where this is not good is when the device-removed signal
is emmitted, the device no longer has the ifname:
$ nmcli monitor
<quit NetworkManager>
(null): device removed
(null): device removed
...
Currently we assert that properties are reset on client teardown. That
is not the right thing to do and we're not going to do that in future.
However, what is important to test is that the properties are reset when
the daemon goes away. Test that.
The part where a device was created and its cleanup on client
description was only run randomly.
This is silly and gave me hard time. No reason not to be always running
it.
This verifies that what's in our public headers has version nodes, and
that they match Since: tags.
Not pretty (because python) but discovered a *lot* of issues.
"gen-metadata-nm-settings-libnm-core.xml" now contains also the names of
the NMSetting types, like "NMSettingConnection". That can be useful
to create NMSetting instances generically (that is, without knowing
the C API that gets called).
So you might be tempted to run
#!/bin/python
import gi
gi.require_version("NM", "1.0")
from gi.repository import GObject, NM
connection = NM.SimpleConnection()
# NM.utils_ensure_gtypes()
gtype_name = "NMSetting6Lowpan"
gtype = GObject.type_from_name(gtype_name)
setting = GObject.new(gtype)
connection.add_setting(setting)
However, without NM.utils_ensure_gtypes() that would not work, because
the GType is not yet created. For a user who doesn't know a priory all
setting types, it's not entirely clear how to make this work. Well, a
GObject introspection user could iterate over al NM.Setting* names and
try to instantiate the classes. However, that is still cumbersome, and not
accessible to a C user (without GI) and the currently loaded libnm
library may be newer and have unknown setting types.
In particular plain C user would need to know to call all the right
nm_setting_*_get_type(), functions, so it needs to know all the existing
52 type getters (and cannot support those from a newer libnm version).
With nm_utils_ensure_gtypes(), the user can get the typename and create
instances generically only using g_type_from_name().
Possible alternatives:
- libnm also has _nm_utils_init() which runs as __attribute__((constructor)).
We could also always instantiate all GType there. However, I don't like running
non-trivial, absolutely necessary code before main().
- hook nm_setting_get_type() to create all GType for the NMSetting
subclasses too. The problem is, that it's not entirely trivial to
avoid deadlock.
- hook nm_connection_get_type() to create all NMSetting types. That
would not deadlock, but it still is questionable whether we should
automatically, at non-obvious times instantiate all GTypes.
These are present in a public header yet are not properly commented,
versioned or exported.
Export them now. Another option would be to move them to a private
header; but I suspect someone has intended them to be exported at some
point.
Add them to @libnm_1_40_4 as opposed to @libnm_1_42_0 because we now know
this is going to be backported to 1.40.4 first.
