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')
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
clang-3.4.2-9.el7 does not like nesting NM_MAX() macro inside nm_hash_update_vals() macro.
Workaround by using MAX() instead. NM_MAX() uses an expression statement and NM_UNIQ()
to evaluate the arguments only once. We don't need that here and glib's MAX() suffices.
CC src/libnm-platform/src_libnm_platform_libnm_platform_la-nm-platform.lo
../src/libnm-platform/nm-platform.c:8247:53: error: in-class initializer for static data member is not a constant expression
(guint8) NM_MAX(obj->weight, 1u));
^
../src/libnm-std-aux/nm-std-aux.h:399:40: note: expanded from macro 'NM_MAX'
#define NM_MAX(a, b) __NM_MAX(NM_UNIQ, a, NM_UNIQ, b)
^
../src/libnm-std-aux/nm-std-aux.h:402:39: note: expanded from macro '__NM_MAX'
typeof(a) NM_UNIQ_T(A, aq) = (a); \
^
../src/libnm-glib-aux/nm-hash-utils.h:124:36: note: expanded from macro 'nm_hash_update_vals'
NM_HASH_COMBINE_VALS(_val, __VA_ARGS__); \
^
Fixes: 8cc41d41fe ('platform: add NM_PLATFORM_IP_ROUTE_CMP_TYPE_ECMP_ID for comparing ECMP base route')
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.
We sometimes have functions foo() and foo_full(), in which case
foo() has fewer arguments and just calls foo_full(). The "full"
function here is the more powerful one, and foo() is implemented
in terms of the former.
nm_platform_ip4_route_cmp_full() and m_platform_ip4_route_cmp() inverted
that pattern. The "_full" there stands for the full comparison, to not
allowing to select the comparison type.
That inconsistency is ugly. Also, these wrappers were used at only few
places. Let's drop them.
While at it, also drop nm_platform_qdisc_cmp() and rename
nm_platform_qdisc_cmp_full(). Here cmp()/cmp_full() followed the common
pattern foo()/foo_full(), but it's still hardly used and unnecessary.
When adding a new route we need to consider it contains extra nexthops
i.e it is a ECMP route. As we cannot modify the NMPObject once created,
we need to pass the extra nexthops as an argument.
We cannot use the original NMPObject because normalization is happening
during when adding the route.
When reading from netlink an ECMP IPv4 route, we need to parse the
multiple nexthops. In order to do that, we are introducing
NMPlatformIP4RtNextHop struct.
The first nexthop information will be kept at the original
NMPlatformIP4Route and the new property n_nexthops will indicate how
many nexthops we need to consider.
This test is inherently fragile, as it depends on starting processes,
wait for something and kill the process. There are timings involved
that are out of control of the test. Try to adjust the timing.
# NetworkManager-DEBUG: <debug> [1668755976.9741] kill child process test-s-4 (111487): sending SIGKILL...
# NetworkManager-DEBUG: <debug> [1668755976.9753] kill child process test-s-4 (111487): waiting for process to terminate after sending SIGTERM (15) and SIGKILL...
# NetworkManager-DEBUG: <debug> [1668755976.9758] kill child process test-s-4 (111487): after sending SIGTERM (15) and SIGKILL, process 111487 exited by signal 9 (5759 usec elapsed)
Bail out! GLib:ERROR:../src/core/tests/test-core-with-expect.c:154:test_nm_utils_kill_child_sync_do: Did not see expected message NetworkManager-DEBUG: *<debug> [*] kill child process test-s-4 (*): waiting up to 1 milliseconds for process to terminate normally after sending SIGTERM (15)...
Bail out! nm:ERROR:../src/core/tests/test-core-with-expect.c:457:test_nm_utils_kill_child: assertion failed (exit_status == 0): (6 == 0)
--- stderr ---
**
GLib:ERROR:../src/core/tests/test-core-with-expect.c:154:test_nm_utils_kill_child_sync_do: Did not see expected message NetworkManager-DEBUG: *<debug> [*] kill child process test-s-4 (*): waiting up to 1 milliseconds for process to terminate normally after sending SIGTERM (15)...
**
nm:ERROR:../src/core/tests/test-core-with-expect.c:457:test_nm_utils_kill_child: assertion failed (exit_status == 0): (6 == 0)
/builds/NetworkManager/NetworkManager/tools/run-nm-test.sh: line 337: 110662 Aborted "${NMTST_DBUS_RUN_SESSION[@]}" "${NMTST_LIBTOOL[@]}" "$NMTST_VALGRIND" --quiet --error-exitcode=$VALGRIND_ERROR --leak-check=full --gen-suppressions=all "${NMTST_SUPPRESSIONS[@]}" --num-callers=100 --log-file="$LOGFILE" "$TEST" "${TEST_ARGV[@]}"
Under normal circumstances, the timeout is not supposed to be hit.
I see it hit on gitlab-ci. Was that because the machine was very
busy? It's hard to say whether there was a legitimate problem here,
and more importantly, what that problem was.
Try to increase the timeout. If there is a real problem, we probably
will still hit the timeout.
We must consume the reference, like we would in the other case.
Interestingly, I am unable to reproduce a case where valgrind would
complain about the leak. But it is there nonetheless.
Fixes: 0a22f4e490 ('libnm: refactor tracking of NMSetting in NMConnection')
See wpa_supplicant commit [1]:
macsec: Make pre-shared CKN variable length
IEEE Std 802.1X-2010, 9.3.1 defines following restrictions for
CKN:
"MKA places no restriction on the format of the CKN, save that it
comprise an integral number of octets, between 1 and 32
(inclusive), and that all potential members of the CA use the same
CKN. No further constraints are placed on the CKNs used with PSKs,
..."
Hence do not require a 32 octet long CKN but instead allow a
shorter CKN to be configured.
This fixes interoperability with some Aruba switches, that do not
accept a 32 octet long CKN (only support shorter ones).
[1] https://w1.fi/cgit/hostap/commit/?id=b678ed1efc50e8da4638d962f8eac13312a4048f
