`which` is convenient, but not installed in Fedora container images.
Fix detection of whether to use `dnf` or `yum`.
(cherry picked from commit 5cc8ca4038)
GCC 10 complains about accesses to elements of zero-length arrays that
overlap other members of the same object:
src/platform/nm-platform-utils.c: In function ‘nmp_utils_ethtool_get_permanent_address’:
src/platform/nm-platform-utils.c:854:29: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u8[0]’ {aka ‘unsigned char[0]’} [-Werror=zero-length-bounds]
854 | if (NM_IN_SET (edata.e.data[0], 0, 0xFF)) {
./shared/nm-glib-aux/nm-macros-internal.h:731:20: note: in definition of macro ‘_NM_IN_SET_EVAL_N’
Fix this warning.
(cherry picked from commit d892a35395)
GCC 10 complains about accesses to elements of zero-length arrays that
overlap other members of the same object:
src/platform/nm-platform-utils.c: In function ‘ethtool_get_stringset’:
src/platform/nm-platform-utils.c:355:27: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u32[0]’ {aka ‘unsigned int[0]’} [-Werror=zero-length-bounds]
355 | len = sset_info.info.data[0];
| ~~~~~~~~~~~~~~~~~~~^~~
In file included from src/platform/nm-platform-utils.c:12:
/usr/include/linux/ethtool.h:647:8: note: while referencing ‘data’
647 | __u32 data[0];
| ^~~~
Fix this warning.
(cherry picked from commit 16e1e44c5e)
I think this solution is not right, because "char buf" is not guaranteed
to have the correct alignment. Revert, and solve it differently.
This reverts commit 6345a66153.
(cherry picked from commit 1fd7e45139)
When we deactivate a virtual device, we usually schedule the deletion
of the link in an idle handler. That action will be executed at a
later time when the device is already in the disconnected state.
Similarly, for ovs interfaces we send the deletion command to the
ovsdb and then proceed to the disconnected state.
However, in the first case there is the guarantee that the link will
be deleted at some point, while for ovs interfaces it may happen that
ovs decides to reuse the same link if there is an addition
queued. Since reusing the same link confuses NM, let's implement
deactivate_async() for ovs-interfaces and wait that the link actually
goes away before proceeding.
https://bugzilla.redhat.com/show_bug.cgi?id=1782701https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/402
(cherry picked from commit 623a1e1f99)
G_SOURCE_FUNC has attribute GLIB_AVAILABLE_MACRO_IN_2_58, which means
that the compiler will emit a warning when GLIB_VERSION_MAX_ALLOWED <
GLIB_VERSION_2_58. We currently define GLIB_VERSION_MAX_ALLOWED as
GLIB_VERSION_2_40. Redefine the macro to fix the following build error
when using glib >= 2.63.5 (the version in which the attribute was
added):
CC shared/nm-glib-aux/libnm_glib_aux_la-nm-shared-utils.lo
shared/nm-glib-aux/nm-shared-utils.c: In function ‘nm_g_unix_fd_source_new’:
shared/nm-glib-aux/nm-shared-utils.c:3679:13: error: Not available before [-Werror]
3679 | g_source_set_callback (source, G_SOURCE_FUNC (source_func), user_data, destroy_notify);
Fixes: 9c5741ccd2 ('shared/nm-glib: add compat implementation for G_SOURCE_FUNC()')
(cherry picked from commit 7f801685b2)
Properly initialize 'overload' when the space in the file section
ends.
shared/n-dhcp4/src/n-dhcp4-outgoing.c: In function ‘n_dhcp4_outgoing_append’:
shared/n-dhcp4/src/n-dhcp4-outgoing.c:198:17: error: ‘overload’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
(cherry picked from commit b2620e798a)
GCC 10 complains about accesses to elements of zero-length arrays that
overlap other members of the same object:
src/platform/nm-platform-utils.c: In function ‘nmp_utils_ethtool_get_permanent_address’:
src/platform/nm-platform-utils.c:854:29: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u8[0]’ {aka ‘unsigned char[0]’} [-Werror=zero-length-bounds]
854 | if (NM_IN_SET (edata.e.data[0], 0, 0xFF)) {
./shared/nm-glib-aux/nm-macros-internal.h:731:20: note: in definition of macro ‘_NM_IN_SET_EVAL_N’
Fix this warning.
(cherry picked from commit 5076fc0ca0)
GCC 10 complains about accesses to elements of zero-length arrays that
overlap other members of the same object:
src/platform/nm-platform-utils.c: In function ‘ethtool_get_stringset’:
src/platform/nm-platform-utils.c:355:27: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u32[0]’ {aka ‘unsigned int[0]’} [-Werror=zero-length-bounds]
355 | len = sset_info.info.data[0];
| ~~~~~~~~~~~~~~~~~~~^~~
In file included from src/platform/nm-platform-utils.c:12:
/usr/include/linux/ethtool.h:647:8: note: while referencing ‘data’
647 | __u32 data[0];
| ^~~~
Fix this warning.
(cherry picked from commit 6345a66153)
Building with GCC 10 gives the following error:
multiple definition of_nm_jansson_json_object_iter_key';
libnm/.libs/liblibnm.a(libnm_core_la-nm-json.o):/builddir/build/BUILD/NetworkManager-1.23.1/libnm-core/nm-json.c:24: first defined here /usr/bin/ld:
libnm/.libs/liblibnm.a(libnm_core_la-nm-team-utils.o):/usr/include/jansson.h:202: multiple definition of _nm_jansson_json_object_iter';
This happens because GCC 10 defaults to -fno-common and so multiple
definitions of the same global variable are not merged together.
_nm_jansson_json_* symbols are defined in nm-json.c as void pointers
and, due to the following macros in nm-json.h:
#define json_object_iter_next (*_nm_jansson_json_object_iter_next)
...
the function declaration in jansson.h:
void *json_object_iter_next(json_t *object, void *iter);
becomes a global variable as well:
void *(*_nm_jansson_json_object_iter_next)(json_t *object, void *iter);
So, the symbol is present in nm-json.o and all other object files that
include nm-json.h, and -fcommon is required. Without it, it would be
necessary to define the symbols only in one place (for example,
nm-json.c), but then static inline functions from the jannson.h header
would still refer to the original (missing) jansson functions.
For the moment, just use -fcommon.
(cherry picked from commit d2d6a68697)
curl_multi_setopt() accepts CURLMOPT_* options, not CURLOPT_*
ones. Found by GCC 10:
clients/cloud-setup/nm-http-client.c:700:38: error: implicit conversion from ‘enum <anonymous>’ to ‘CURLMoption’ [-Werror=enum-conversion]
700 | curl_multi_setopt (priv->mhandle, CURLOPT_VERBOSE, 1);
Fixes: 69f048bf0c ('cloud-setup: add tool for automatic IP configuration in cloud')
(cherry picked from commit c11ac34f4c)
As it is possible to configure an arbitrarily large DHCP timeout, it
should be possible to also set a large timeout for IPv6
autoconfiguration. Currently the timeout can only be changed via
sysctl. Leave the lower bound because the default kernel sysctl value
is 3 * 4 = 12 seconds and so without the lower limit the default
timeout would change from 30 to 12 seconds for every user, which seems
a big change and could possibly break users' setup.
https://bugzilla.redhat.com/show_bug.cgi?id=1795957
(cherry picked from commit d8e1f4c8ef)
If the current lease expires, we start the grace period in which the
clients starts again from the INIT DHCP state (i.e. sending DISCOVER
messages). If it is able to obtain a new lease, it must be accepted or
otherwise the client will not renew it.
(cherry picked from commit df75c21b4d)
Currently the DHCP client reports the BOUND state not only when the
lease is obtained initially but also when it is renewed. Having a
different state for the renewal will be used by NMDevice in the next
patch to determine whether the lease needs to be accept()ed or not.
(cherry picked from commit a4ddb56923)
Move back to INIT state after the lease expires, as per section 4.4.5
of RFC 2131. Previously the client just moved to EXPIRED, closed the
connection and cleared the probe, leaving to the caller of the library
the choice to create a new client instance and to start from
scratch. However, it seems more useful that the client, once
initialized, always tries to get a lease even after an expiration.
(cherry picked from commit 182a8021f3)
Currently the duration of the DHCP grace period (in which we try to
acquire a new lease after expiration) is hardcoded to 480
seconds. That value seems arbitrary and too long for the default
configuration. Since we already have a property that allows the user
to configure how long NM should try to get the lease initially, it
makes sense to use it also for retries after lease expirations.
In particular, setting the ipvx.dhcp-timeout to a high value extends
also the grace period to a very long time, potentially forever.
(cherry picked from commit aee78ca788)
The signal is unused (and should be removed).
Still, the parameter passed to g_signal_emit() is a C string, not a
GVariant. I think as there are no subscribers, glib wouldn't actually
do anything with the arguments. Though, I am not sure whether glib still
tries to initialize a GValue with a GVariant type, leading to a crash.
Fixes: f05b7a78c9 ('supplicant: Track P2P Group information, creation and destruction')
(cherry picked from commit c106008091)
Don't realize a virtual device if the master is missing because in
such case the autoactivation can't start and a stale link will be
created.
(cherry picked from commit 336bfcabc4)
Add a 'in-state-change' pending action to be sure the device always has a
pending when transitioning between states (this prevents callbacks to mark
startup as complete while running _set_state_full()).
This is needed as during the 'failed'->'disconnected' the pending action 'activation-*'
for the device is removed resulting in an empty pending_actions list which then
triggers 'check_if_startup_complete()' that will find no pending action and mark
startup as complete even if the device could have been activated with another connection.
https://bugzilla.redhat.com/show_bug.cgi?id=1759956
(cherry picked from commit f583aec806)
The option is mandatory in the replies from server and so we don't
need to ask for it. dhclient doesn't do it either. But especially, it
seems that requesting the option causes some broken server
implementations to send duplicate instances of the option.
So, remove the option from the parameter request list of the internal
nettools and systemd DHCP implementation.
(cherry picked from commit 541db78259)
If the server sends a packet with multiple instances of the same
option, they are concatenated during n_dhcp4_incoming_linearize() and
evaluated as a single option as per section 7 of RFC 3396.
However, there are broken server implementations that send
self-contained options in multiple copies. They are reassembled to
form a single instance by the nettools client, which then fails to
parse them because they have a length greater than the expected one.
This problem can be reproduced by starting a server with:
dnsmasq --bind-interfaces --interface veth1 -d
--dhcp-range=172.25.1.100,172.25.1.200,1m
--dhcp-option=54,172.25.1.1
In this way dnsmasq sends a duplicate option 54 (server-id) when the
client requests it in the 'parameter request list' option, as
dhcp=systemd and dhcp=nettools currently do.
While this is a violation of the RFC by the server, both isc-dhcp and
systemd-networkd client implementations have mechanisms to deal with
this situation. dhclient simply takes the first bytes of the
aggregated option. systemd-networkd doesn't follow RFC 3396 and
doesn't aggregate multiple options; it considers only the last
occurrence of each option.
Change the parsing code to accept options that are longer than
necessary.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/324
(cherry picked from commit 1cbf9d22a5)
We now move the deletion of the context-busy-watcher to and idle handler
on the D-Bus GMainContext.
Note that the idle source does not take an additional reference on the
context. Hence, in certain cases it might happen that the context will
be completely unrefed before the idle handler runs. In that case, we
would leak the object.
Avoid that, by taking an additional reference to the GMainContext.
Note that the alternative would be to unref the context-busy-watcher
via the GSource's GDestroyNotify. That is not done, because then the
busy watcher might be unrefed in a different thread. Instead, we want
that to happen for the right context. The only minor downside of this
is that the user now always pays the price and must iterate the context
to fully clean up. But note that the user anyway must be prepared to
iterate the context after NMClient is gone. And that depends on some
unpredictable events that the user cannot control. That means, either
the user handles this correctly already, or the problem anyway exists
(randomly).
Of course all of the discussed "problems" are very specific. In practice, the
users uses the g_main_context_default() instance and anyway will either
keep iterating it or quit the process after the NMClient instance goes
away.
(cherry picked from commit c2f8400e66)
The context-busy-watch has two purposes:
1) it allows the user to watch whether the NMClient still has pending
GSource'es attached to the GMainContext.
2) thereby, it also keeps the inner GMainContext integrated into the
caller's (in case of synchronous initialization of NMClient).
Especially for 2), we must not get this wrong. Otherwise, we might
un-integrate the inner GMainContext too early and it will be leaked
indefinitely (because the user has no means to access or iterate it).
To be extra careful, extend the lifetime of the context-busy-watcher
for one more idle invocation. Theoretically, this should not be necessary,
but it's not clear whether something else is still pending.
The downside of that extra safety is that it is probably unnecessary in
practice. And in case where it is necessary, it hides an actual
issue, making it harder to notice and fix it.
(cherry picked from commit b572c0542a)
When passing a destroy notify to g_dbus_connection_signal_subscribe(),
that callback gets invoked as an idle handler of the associated
GMainContext. That caused to have yet another source attached to the
context after the NMClient gets destroyed.
Especially with synchronous initialization of NMClient that is bad,
because we may destroy the context-busy-watcher too early. That results
in removing the integration of the inner GMainContext into the caller's
context, and thus we leak the inner context indefinitely.
Avoid that leak by not passing a cleanup function to
g_dbus_connection_signal_subscribe().
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
(cherry picked from commit e280124757)
Groups currently are not exposed on D-Bus as separate objects.
Also, we might want to expose the property as "ao" instead of "as".
This API needs more thought.
There are likely no users that rely on this property. So, we will
drop it from server side, until it will be requested and newly designed.
Regardless, NMClient needs to gracefully ignore the property.
Despite we will remove it from 1.24 API, libnm should ignore the
property on previous versions. Mark it accordingly.
(cherry picked from commit 05f66697e4)
