They serve a similar purpose.
Previously, nm-json-aux.h contained the virtual function table for accessing
the dynamically loaded libjansson. But there is no reason why our own
helper functions from nm-json.h cannot be there too.
We anyway load libjansson with dlopen(), and already before it could
happen that libjansson is not available. In that case, we would not
crash, but simply proceed without json validation.
Since libnm-core no longer uses libjansson directly, but only via
"nm-glib-aux/nm-json.h", we can just always compile with that, and use
it at runtime. That means, libjansson is not a build dependency for
libnm anymore, so we don't need a compile time check.
Note that if you build without libjansson, then JANSSON_SONAME is
undefined, and loading it will still fail at runtime. So, even if
we now always build with all our code enabled, it only works if you
actually build with libjansson. Still, it's simpler to drop the
conditional build, as the only benefit is a (minimally) smaller
build.
nm-json.[hc] uses libjansson, but only loads it at runtime with dlopen. There
is no more run compile time dependency. Move it to shared, so that it can be
(theoretically) used by other components.
Also, drop the conditional compilation. Granted, if you don't build with
libjansson enabled, then the JANSSON_SONAME define is unset and the code
will fail to load at runtime (which is fine). However, we can still build
against our JSON wrappers. The code savings of conditional build are minimal
so drop it.
It's error prone to include the header and trying not to use it.
Don't include <jansson.h>. Instead, redefine our nm variants of
everything.
Note that we only redefine stuff that is in public headers (like
"json_t" typedef). libjansson anyway must not change the struct layout
and the like, without breaking all applications. That is because the
non-opaque code from the header anyway is part of the applications that
include it. Later we will add additional unit test that checks that our
redefinition matches to what we had at compile time.
"shared/nm-glib-aux/nm-jansson.h" is a compat header for <jansson.h>. It
includes <jansson.h> and adds some compatibility workarounds and helper
functions.
We want that "libnm-core/nm-json.h" no longer includes <jansson.h>, so
that we don't accidentally use symbols from there.
Hence, "libnm-core/nm-json.h" must no longer include "nm-jansson.h".
In preparation of that, copy the content of "shared/nm-glib-aux/nm-jansson.h"
also to "libnm-core/nm-json.h". It will be reworked later.
Some symbols in jansson.h are macros, some are regular functions,
and some are inline functions.
Regular functions must not be used directly, only via dlsym().
Macros must be used directly, but it is non-obvious which symbols
are macros. Hence, for each json_* macro add an nm_json_* alias.
Inline functions are a bit odd. If they are inlined and don't use
any non-inlined symbols from libjansson, they could be used directly.
However, it's non obvious whether both of the conditions are met.
Hence, we reimplement them in nm-json.h. The only function of this kind
is json_decref().
The point is to not use any json_* symbols directly -- except structs
and typedefs.
Seemingly, with this change we don't use any jansson symbols directly.
However, that is not true, as macros like nm_json_object_foreach()
still are implemented based on what is included from <jansson.h>.
Hence, we cannot drop patching the included jansson.h header yet and
still need our wrapper functions.
Rework the code how we access libjansson.
libnm wants to use libjansson, but it doesn't directly link to it.
The reason is that (until recently), libjansson has conflicting symbols
with libjson-c and libjson-glib. That means, if libnm would directly
link against libjansson, then if the using application happens to drag
in one of the conflicting libraries, the application would crash. Instead,
we dlopen() the library (with flags RTLD_LOCAL|RTLD_DEEPBIND).
However, as it is currently done, it doesn't fully work, as unit test
failures of libnm show on Debian sid (where libmount links against
libcryptsetup which links against libjson-c). Theoretically, our current
approach should work. At least for libnm; not for the OVS and team
plugins which use libjansson directly in NetworkManager core.
What I dislike about the current approach is that we still include
<jansson.h>, but somehow try not to use any symbols from it (via #define
we remap the json functions). The previous approach is "smaller", but also highly
confusing, and error prone, as there is a subtle bug as the unit test failure
shows (which I don't understand).
Instead, add and load a virtual function table NMJsonVt. Later, we will
go further ad drop all direct uses of <jansson.h> header.
Pre-generate routes in the local table that are configured
by kernel when an ip-address is assigned to an interface.
This helps NM taking into account routes that are not to be deleted
when a connection is reapplied (or deactivated) on an interface instead of only
ignoring (when pruning) IPv6 routes having metric 0 and routes belonging
to the local table having 'kernel' as proto.
https://bugzilla.redhat.com/show_bug.cgi?id=1821787
@routes are the list of routes we want to configure. This contains
routes from DHCP and manual routes in the profile. It also contains
externally present routes, including the metric=0 routes in the local
table.
Trying to add an IPv6 route with metric zero adds instead a route with
metric 1024.
Usually, we wouldn't do that, because that route was present externally,
so it possibly is still present (in the platform cache) during sync and
we skip the addition. However, there is a race where the external route
might just disappear and we'd add a route with metric 1024.
Avoid that.
NM will now sync all tables when a connection has specified
at least 1 local route in 'ipv[4|6].routes' to correctly
reconcile local routes when reapplying connections on a device.
If the connection has no local routes only the main table will be
taken into account preserving the previous NM's behaviour.
https://bugzilla.redhat.com/show_bug.cgi?id=1821787
Pre-generate the device multicast route in the local table that are configured
by kernel when an ipv6-address is assigned to an interface.
This helps NM taking into account routes that are not to be deleted
when a connection is reapplied on an interface.
https://bugzilla.redhat.com/show_bug.cgi?id=1821787
NetworkManager can't control the name of the PPP interface name
created by pppd; so it has to wait for the interface to appear and
then rename it. This happens in nm_device_take_over_link() called by
nm-device-ppp.c:ppp_ifindex_set() when pppd tells NM the ifindex of
the interface that was created.
However, sometimes the initial interface name is already correct, for
example when the connection.interface-name is ppp0 and this is the
first PPP interface created.
When this happens, nm_device_update_from_platform_link() is called on
the NMDevicePPP and it sets the device ifindex. Later, when pppd
notifies NM, nm_device_take_over_link() fails because the ifindex is
already set:
nm_device_take_over_link: assertion 'priv->ifindex <= 0' failed
Make nm_device_take_over_link() more robust to cope with this
situation.
https://bugzilla.redhat.com/show_bug.cgi?id=1849386
NetworkManager can't control the name of the PPP interface name
created by pppd; so it has to wait for the interface to appear and
then rename it. This happens in nm_device_take_over_link() called by
nm-device-ppp.c:ppp_ifindex_set() when pppd tells NM the ifindex of
the interface that was created.
However, sometimes the initial interface name is already correct, for
example when the connection.interface-name is ppp0 and this is the
first PPP interface created.
When this happens, nm_device_update_from_platform_link() is called on
the NMDevicePPP and it sets the device ifindex. Later, when pppd
notifies NM, nm_device_take_over_link() fails because the ifindex is
already set:
nm_device_take_over_link: assertion 'priv->ifindex <= 0' failed
Make nm_device_take_over_link() more robust to cope with this
situation.
https://bugzilla.redhat.com/show_bug.cgi?id=1849386
The output of nm_utils_format_variant_attributes() must be accepted by
nm_utils_parse_variant_attributes(), producing the initial attributes.
The latter has a special handling of some attributes, depending on the
input NMVariantAttributeSpec list. For example, if the
NMVariantAttributeSpec is a boolean with the 'no_value' flag, the
parser doesn't look for a value.
Pass the NMVariantAttributeSpec list to the format function so that it
can behave in the same way as the parse one.
Support the creation of parameterless 'prio' qdiscs. The kernel needs
a TCA_OPTIONS attribute initialized with default values. We currently
don't support modifying the qdisc parameters.
There is the team of nm_auto*, nm_clear_pointer() and nm_steal_pointer().
These goes nicely together so that an autovariable owns a resource,
to free it (clear) and to transfer ownership (steal).
We have these also in glib, but we certainly also need it if we don't
have glib because that very much goes together with nm_auto*. Add it.
Previously, we did not have a hard dependency on C99. Nowadays, we
actually build against C11, so we have <stdbool.h>. These definitions
are no longer necessary nor do we care about building against plain
C89.
For a long time already we build with gnu11/C11. We thus rely on having
<stdbool.h> around, which is C99. Use it.
Also fix "nm-std-aux.h" to not use TRUE/FALSE glib defines.
We redefine _G_BOOLEAN_EXPR(), so let it use NM_BOOLEAN_EXPR().
Also, we use G_LIKELY() (and thus NM_BOOLEAN_EXPR()) inside nm_assert(),
and we use nm_assert() in some macros. To be able to nest nm_assert()
calls, we need to create unique variable names for NM_BOOLEAN_EXPR().
Userspace cannot add IPv6 routes with metric 0. Trying to do that, will
be coerced by kernel to route metric 1024. For IPv4 this is different,
and metric zero is commonly allowed.
However, kernel itself can add IPv6 routes with metric zero:
# ip -6 route show table local
local fe80::2029:c7ff:fec9:698a dev v proto kernel metric 0 pref medium
That means, we must not treat route metric zero special for most cases.
Only, when we want to add routes (based on user configuration), we must
coerce a route metric of zero to 1024.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/563
Having assertion macros that are disabled by default, is not
only useful for our glib code, but should also be available
for nm-std-aux. Move the macros.
nm_device_cleanup() can be called when the device no longer has an
ifindex. In such case, don't try to reset the MAC address as that
would lead to an assertion failure.
We already set the MAC of OVS interfaces in the ovsdb. Unfortunately,
vswitchd doesn't create the interface with the given MAC from the
beginning, but first creates it with a random MAC and then changes it.
This causes a race condition: as soon as NM sees the new link, it
starts IP configuration on it and (possibly later) vswitchd will
change the MAC.
To avoid this, also set the desired MAC via netlink before starting IP
configuration.
https://bugzilla.redhat.com/show_bug.cgi?id=1852106https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/483
When a user creates a ovs-interface with the same name of the parent
ovs-bridge, openvswitch considers the interface as the "local
interface" [1] and assigns the MAC address of the bridge to the
interface [2].
This is confusing for users, as the cloned MAC property is ignored in
some cases, depending on the ovs-interface name.
Instead, detect when the interface is local and set the MAC from the
ovs-interface connection in the bridge table.
[1] https://github.com/openvswitch/ovs/blob/v2.13.0/vswitchd/vswitch.xml#L2546
[2] https://github.com/openvswitch/ovs/blob/v2.13.0/vswitchd/bridge.c#L4744
