We put all these structs inside the tagged union NMPObject.
Also, in a sense NMPlatformObject is the base "type" of all
these structs, meaning, it should be able to up and downcast.
Ensure the alignment matches.
This helps to avoid "-Wcast-align" warnings when trying to cast
a (NMPlatformObject*) to another (NMPlatformXXX *) type. Something
we commonly do.
nm_g_array_first_p() is a convenient helper to get the pointer to
the first index. But this one should also accept that the array is NULL,
has array->data as NULL or is empty.
nm_utils_get_ipv6_interface_identifier() has non-obvious requirements on
the hardware address. If the caller passes a wrong length, it will
trigger an assertion or even cause out of bound read. This would mean
that the caller needs to carefully check the length. Such requirements
on the caller are wrong.
Also, in practice the hardware length comes from platform/kernel. We
don't want to trust that what kernel tells us always has the required
address length, so the caller would always have to double check before
calling the function.
Instead, handle unexpected address lengths.
Fixes: e2270040c0 ('core: use Interface Identifiers for IPv6 SLAAC addresses')
Fixes: 1d396e9972 ('core-utils: use 64-bit WPAN address for a 6LoWPAN IID')
For link type NM_LINK_TYPE_6LOWPAN, nm_utils_get_ipv6_interface_identifier()
expects 8 bytes hardware address. It even just accesses the buffer
without checking (that needs to be fixed too).
For 6lowpan devices, the caller might construct a fake ethernet MAC
address, which is only 6 bytes long. So wrong.
Fixes: 49844ea55f ('device: generate pseudo 48-bit address from the WPAN short one')
- with nm_assert(), if the argument is a compile time constant
always check it (regardless of NDEBUG, G_DISABLE_ASSERT)
and mark the failure as _nm_unreachable_code(). We do this,
even if we usually would not evaluate run time checks with
NDEBUG/G_DISABLE_ASSERT.
- with nm_assert_se(), if assertions are disabled with NDEBUG
and G_DISABLE_ASSERT, still mark the path as _nm_unreachable_code().
This is useful, because it can avoid compiler warnings that are
emitted if the compiler things that the code can be reached.
_nm_assert_fail() can clearly never be reached (unless a bug happens).
When compiling we can disable assertion checks with
NDEBUG/G_DISABLE_ASSERT, but if we know that an assertion must not be
hit (for example with nm_assert_not_reached()) then we still want to
mark the path as unreachable, even if assert() does not abort the
process.
This allows the compiler to see that nm_assert(0) is unreachable code.
That is because nm_assert(0) calls NM_LIKELY(0), which calls
NM_BOOLEAN_EXPR(0). The latter was a statement expression, which
to the compiler was not a constant expression. Hence, this may trigger
compiler warnings about uninitialized variables.
Let NM_BOOLEAN_EXPR() to be constant, if the arguments are.
This can avoid compiler warnings in some cases.
Note that __builtin_choose_expr(__builtin_constant_p(...), ...) does
not properly work with gcc 4.8 ([1]). Hence only do macro shenanigans
with a newer gcc. Then entire point of NM_BOOLEAN_EXPR() is anyway
to preserve the "-Wparentheses" warning (while only evaluating the
argument once, being safe with nested invocations, propagate constness).
If we don't care about "-Wparentheses", it should be the same as
(!!(expr)). We can ignore that on non-recent gcc.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19449
Glib 2.58+ improved the implementation of the g_clear_pointer() macro,
and indirectly of g_clear_object(), which uses it.
Note that we don't use the 2.58+ version, because our GLIB_VERSION_MAX_ALLOWED
is too old.
Also note that we don't use g_clear_pointer() directly. Instead, we have
and use nm_clear_pointer() everywhere.
Still, it would be nice if also g_clear_object() uses the improved
variant. Arguably, this is less relevant, because g_clear_object() calls
g_unref_object() which accepts a void pointer and thus there isn't much
type-safety to gain. Still, there is a small gain, so do it.
We could:
1) replace all uses of g_clear_object() with nm_clear_g_object() and outlaw
both g_clear_object() and g_clear_pointer(). This is what's done for
nm_clear_pointer(), which should be used instead of g_clear_pointer().
The advantage is that we don't monkey-patch glib (which might surprise users).
The disadvantage is that g_clear_pointer() is well known, while nm_clear_pointer()
is not. This is mitigated by the fact that nm_clear_pointer() behaves very similar
to g_clear_pointer() and in all cases where you legally could use
g_clear_pointer(), nm_clear_pointer() works to the same effect (but not vice
versa).
2) silently redefine the glib helper to use our improved implementation. This is
done for g_clear_error(), which is redefined to nm_clear_error().
The advantage is that it appears as if we would use glib functionality.
The disadvantage is that this is not exactly the glib variant.
This too is mitigated by the fact that our patched g_clear_error()
should work the same, wherever you can legally use glib's variant (but not
vice versa).
Let's do 2).
In this case, let g_clear_pointer() behaves exactly like glib 2.58+'s variant,
and not like nm_clear_pointer(). This is to reduce any potential surprise.
nm_clear_pointer() is still better. Still use that over
g_clear_pointer(). This change is for g_clear_object().
The fields "l3cfg" and "l3cfg_" are union aliases. One of them is const,
the other is not. The idea is that all places that modify the field need
to use the special name "l3cfg_", and grepping for that will lead you to
all the relevant places.
This mistake happened, because g_clear_object() casts constness away.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
"connection" variable might be NULL, which fails an assertion in
g_dbus_connection_flush_sync(). Consequently, "error_flush" is also
NULL which leads to a crash of "nm-dhcp-helper".
Reported-by: Jules Maselbas <jmaselbas@zdiv.net>
Fixes: 240ec7f891 ('dhcp: implement ACD (address collision detection) for DHCPv4')
A loopback interface cannot be attached to a controller interface (in kernel).
Also, we have special handling for the loopback address 127.0.0.1. It's
not clear how that should behave when the loopback device would be
attached to another interface.
Just reject such configuration as invalid.
Fixes: e8618f03d7 ('support loopback interface')
python-setuptools is now gone from debian:testing ([1], [2]):
Package python-setuptools is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'python-setuptools' has no installation candidate
This package is entirely optional. Fix the failure by ignoring any failure to
install the package.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938168
[2] https://tracker.debian.org/news/1391360/python-setuptools-removed-from-testing/
c37722ff2f55 generic: use _c_boolean_expr_() in _c_{likely,unlikely}_()
8baa8831b17a generic: add _c_boolean_expr_() to preserved "-Wparentheses" warning
2cda8dc53a9a generic: use _c_likely_() in c_assert()
git-subtree-dir: src/c-stdaux
git-subtree-split: c37722ff2f5525caa6680e6114333222a9d468a4
openvswitch accepts "dot1q-tunnel" as vlan mode:
A dot1q-tunnel port is somewhat like an access port. Like an
access port, it carries packets on the single VLAN specified
in the tag column and this VLAN, called the service VLAN,
does not appear in an 802.1Q header for packets that ingress
or egress on the port. The main difference lies in the be‐
havior when packets that include a 802.1Q header ingress on
the port. Whereas an access port drops such packets, a
dot1q-tunnel port treats these as double-tagged with the
outer service VLAN tag and the inner customer VLAN taken
from the 802.1Q header. Correspondingly, to egress on the
port, a packet outer VLAN (or only VLAN) must be tag, which
is removed before egress, which exposes the inner (customer)
VLAN if one is present.
Support this mode.
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.
In some scenarios, autoconnect should not be blocked if the device is
activated on the external connection (e.g. autoconnect on the loopback
device).
Adding the `allow_autoconnect_on_external` flag to support such
behavior.
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
We soon will handle loopback, so -- if no loopback profile is activated
in NetworkManager -- we will have an externally managed profile on
loopback. This messes up the result.
In general, external connections don't make much sense for
build_device_hostname_infos(). Ignore them.
any_devices_active() exists to avoid hostname update when no devices are
active. See [1] and commit b07f6712e9 ('policy: check for active
devices before triggering dns update on hostname change').
Soon, we will add support for loopback device, so "lo" will
almost always be activated (either externally or actively managed by
NetworkManager).
In any case, external devices should not count here, even if they appear
activating/activated.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1344303
The implementation for static asserts with (sizeof(char[(cond) ? 1 : -1]))
silently fails if the condition is not a compile time constant, because
it results in a VLA which is evaluated at runtime. Well, for that reason
we build with "-Wvla" to catch accidentally using a non-const expression
in a static assert. But still, we can do better. Use instead bitfields
to trigger the compiler error. This works only with static expressions
and also without "-Wvla".
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1468
2d3877aabd7d docs: avoid duplicate headers
ba751b517888 c-stdaux: be more consistent with #ifdef
9796f4a63a4b c-stdaux: move _c_always_inline_ to *-generic
34067b3a5f4f c-stdaux: avoid declspec-fallback for _c_public_
82b82245cf36 c-stdaux: expose _c_public_ in *-generic
37fa624afcd6 docs: set C_COMPILER_DOCS
7197bc75f829 docs: add ./src to include path
34ed5b2c4b52 test-basic: avoid _c_unused_
00cc51c99c64 test-basic: fix *_gnuc() fallback to have an argument
6a9262c168f7 test-basic: use strtol() over close() to set errno
807d4a704757 test-basic: guard cleanup-tests by GNUC
13f65ad8c27c test-basic: separate tests by module
fdf399ef7f5b test-api: only test for available APIs
1f9cfe8e3b2f c-stdaux: export C_MODULE_*
65bf768151e3 c-stdaux: move GNUC-macros into separate module
6549fa0eb8f3 c-stdaux: extract unix'ish code into separate module
d69c3c0fe7ee c-stdaux: split off portable code
132d82a37607 c-stdaux: add C_COMPILER_DOCS documentation
053b2d9f1c11 c-stdaux: avoid ctx-expr in c_assert()
e75f32c2e046 c-stdaux: fix typo in c_assert() docs
d75a2350ae22 c-stdaux: stub likely/unlikely as fallback
eb90a0d0fced c-stdaux: fix documentation of likely/unlikely
57f332c53184 c-stdaux: fix typo in c_closedir() docs
f3d6b60400d3 c-stdaux: add _c_always_inline_
8d017b02cf12 c-stdaux: provide target identification
3d8f78f964ff ci: enable windows builds
git-subtree-dir: src/c-stdaux
git-subtree-split: 2d3877aabd7d0e813f4a153ac262ee83b3c04793
a4144785ab77 docs: include ./src in include path
efd6619234cd docs: use c-apidocs glob
git-subtree-dir: src/c-rbtree
git-subtree-split: a4144785ab77ecc0627898c7c60523b2368c6ecb
When the test in gitlab-ci fails, you might want to rerun the test
on your machine. You fire up podman, run "./.gitlab-ci/*-install.sh"
and "./.gitlab-ci/run-test.sh".
Make it possible to manually select parts that are tested by
"run-test.sh" by setting NM_TEST_SELECT_RUN. Otherwise, if you want to
test a particular configuration, you either have to run all earlier
steps (which takes a long time and can even be broken) or you have
to manually patch the file.
For example,
NM_TEST_SELECT_RUN=6 ./.gitlab-ci/run-test.sh
