We're going to extend those to issue methods other than GET.
Also, "request" would've been too long, "req" looks nicer.
Conflicts: code formatting, missing trivial commit in,
provider-azure, missing 494819bbbf ("cloud-setup: move common
code for get_config() to base class and improve cancellation")
(cherry picked from commit 85ce088616)
(cherry picked from commit 6e8cfbae32)
(cherry picked from commit 20cd11ee49)
(cherry picked from commit 9ce530fa7a)
(cherry picked from commit d6d161a31d)
(cherry picked from commit 977fc2c8c5)
(cherry picked from commit 89ee76409b)
(cherry picked from commit e3d23c7ee0)
No need to do a deep clone. The strv array is not ever modified and we
pack it together in one memory allocation.
Conflicts: nm_strv_dup_packed is still called nm_utils_strv_dup_packed.
Code formatting.
(cherry picked from commit 599fe234ea)
(cherry picked from commit 3787eacac9)
(cherry picked from commit 89a6ce575d)
(cherry picked from commit d14dc95be3)
(cherry picked from commit 7e516418e0)
(cherry picked from commit becb47826a)
(cherry picked from commit 4704e14100)
(cherry picked from commit 23b03def98)
(cherry picked from commit b52cbad24b)
It's not used anywhere.
Conflicts: code formatting only
(cherry picked from commit ce225b2c06)
(cherry picked from commit 23b9514080)
(cherry picked from commit 36d417af60)
(cherry picked from commit d83537bff5)
(cherry picked from commit f584b9c97b)
(cherry picked from commit f59f629431)
(cherry picked from commit 1885ff2c65)
(cherry picked from commit cab0b16d3c)
(cherry picked from commit 3a55788885)
If the TC setting contains no qdiscs and filters, it is lost after a
write-read cycle. Fix this by adding a new property to indicate the
presence of the (empty) setting.
(cherry picked from commit 6a88d4e55c)
(cherry picked from commit acf0c4df2b)
(cherry picked from commit 4efcdf234d)
NetworkManager supports a very limited set of qdiscs. If users want to
configure a unsupported qdisc, they need to do it outside of
NetworkManager using tc.
The problem is that NM also removes all qdiscs and filters during
activation if the connection doesn't contain a TC setting. Therefore,
setting TC configuration outside of NM is hard because users need to
do it *after* the connection is up (for example through a dispatcher
script).
Let NM consider the presence (or absence) of a TC setting in the
connection to determine whether NM should configure (or not) qdiscs
and filters on the interface. We already do something similar for
SR-IOV configuration.
Since new connections don't have the TC setting, the new behavior
(ignore existing configuration) will be the default. The impact of
this change in different scenarios is:
- the user previously configured TC settings via NM. This continues
to work as before;
- the user didn't set any qdiscs or filters in the connection, and
expected NM to clear them from the interface during activation.
Here there is a change in behavior, but it seems unlikely that
anybody relied on the old one;
- the user didn't care about qdiscs and filters; NM removed all
qdiscs upon activation, and so the default qdisc from kernel was
used. After this change, NM will not touch qdiscs and the default
qdisc will be used, as before;
- the user set a different qdisc via tc and NM cleared it during
activation. Now this will work as expected.
So, the new default behavior seems better than the previous one.
https://bugzilla.redhat.com/show_bug.cgi?id=1928078
(cherry picked from commit a48edd0410)
(cherry picked from commit 2a8181bcd7)
(cherry picked from commit de1449375a)
gcc-11.0.0-0.7.fc34 warns here:
CC libnm-core/libnm_core_la-nm-setting-team.lo
libnm-core/nm-setting-team.c: In function ‘nm_team_link_watcher_new_ethtool’:
libnm-core/nm-setting-team.c:127:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
127 | watcher->ref_count = 1;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:128:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
128 | watcher->type = LINK_WATCHER_ETHTOOL;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:129:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
129 | watcher->ethtool.delay_up = delay_up;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libnm-core/nm-setting-team.c:130:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
130 | watcher->ethtool.delay_down = delay_down;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’
125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Maybe we should not use this trick and just malloc() a struct of the
intended size, however:
- the code below does a similar thing, doing it differently for ethtool
watcher is confusing.
- the NMTeamLinkWatcher is a union which cannot alter its type. In no
case is it correct to access the fields of the wrong union type. By
allocating a smaller chunk, valgrind might catch such bugs.
Also, NMTeamLinkWatcher's definition is private to the C source file,
in no case must anybody assume that the rest of the buffer actually
exists.
Hence, workaround the warning by suppressing it.
(cherry picked from commit e5699dbcb7)
(cherry picked from commit 221547bc21)
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
(cherry picked from commit 6b64fac06d)
(cherry picked from commit 950b7d573b)
(cherry picked from commit 2695d10278)
The goal of this code is to detect python, but prefer python3 while
also allowing the user to override the path.
That did not work in all cases, due to what seems like a bug in
AM_PATH_PYTHON(). AM_PATH_PYTHON() is documented to ignore failure
if [action-if-not-found] is given. So one might assume that:
AM_PATH_PYTHON([3], [], [PYTHON=])
if test -z "$PYTHON"; then
AM_PATH_PYTHON([], [], [PYTHON=python])
fi
first tries to look for v3, and if that fails search for any python
interpreter. That did not work however with:
$ ./configure PYTHON=/usr/bin/python2
...
checking pkg-config is at least version 0.9.0... yes
checking whether /usr/bin/python2 version is >= 3... no
configure: error: Python interpreter is too old
because the first AM_PATH_PYTHON() is fatal.
Work around that.
Fixes: 54a1cfa973 ('build: prefer python3 over python2 in autotools's configure script')
(cherry picked from commit 91bf576a43)
(cherry picked from commit 58a24f4f66)
(cherry picked from commit 7cb48c4608)
It's not entirely clear how to treat %NULL.
Clearly "match.interface-name=eth0" should not
match with an interface %NULL. But what about
"match.interface-name=!eth0"? It's now implemented
that negative matches still succeed against %NULL.
What about "match.interface-name=*"? That probably
should also match with %NULL. So we treat %NULL really
like "".
Against commit 11cd443448 ('iwd: Don't call IWD methods when device
unmanaged'), we got this backtrace:
#0 0x00007f1c164069f1 in __strnlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62
#1 0x00007f1c1637ac9e in __fnmatch (pattern=<optimized out>, string=<optimized out>, string@entry=0x0, flags=flags@entry=0) at fnmatch.c:379
p = 0x0
res = <optimized out>
orig_pattern = <optimized out>
n = <optimized out>
wpattern = 0x7fff8d860730 L"pci-0000:03:00.0"
ps = {__count = 0, __value = {__wch = 0, __wchb = "\000\000\000"}}
wpattern_malloc = 0x0
wstring_malloc = 0x0
wstring = <optimized out>
alloca_used = 80
__PRETTY_FUNCTION__ = "__fnmatch"
#2 0x0000564484a978bf in nm_wildcard_match_check (str=0x0, patterns=<optimized out>, num_patterns=<optimized out>) at src/core/nm-core-utils.c:1959
is_inverted = 0
is_mandatory = 0
match = <optimized out>
p = 0x564486c43fa0 "pci-0000:03:00.0"
has_optional = 0
has_any_optional = 0
i = <optimized out>
#3 0x0000564484bf4797 in check_connection_compatible (self=<optimized out>, connection=<optimized out>, error=0x0) at src/core/devices/nm-device.c:7499
patterns = <optimized out>
device_driver = 0x564486c76bd0 "veth"
num_patterns = 1
priv = 0x564486cbe0b0
__func__ = "check_connection_compatible"
device_iface = <optimized out>
local = 0x564486c99a60
conn_iface = 0x0
klass = <optimized out>
s_match = 0x564486c63df0 [NMSettingMatch]
#4 0x0000564484c38491 in check_connection_compatible (device=0x564486cbe590 [NMDeviceVeth], connection=0x564486c6b160, error=0x0) at src/core/devices/nm-device-ethernet.c:348
self = 0x564486cbe590 [NMDeviceVeth]
s_wired = <optimized out>
Fixes: 3ced486f41 ('libnm/match: extend syntax for match patterns with '|', '&', '!' and '\\'')
https://bugzilla.redhat.com/show_bug.cgi?id=1942741
CVE-2021-20297
(cherry picked from commit 420784e342)
(cherry picked from commit eaba0b4845)
(cherry picked from commit 16e5b307a3)
Add support for `carrier-wait-timeout` setting from kernel cmdline.
This will create a new `15-carrier-timeout.conf` file in
/run/NetworkManager/conf.d with the parameter value as specified.
The setting also inserts `match-device` to `*`, matching all devices.
NB: The parameter on kernel cmdline is specified in seconds. This is
done to be backwards compatible with with network-legacy module. However
the generated setting will automatically multiply specified value by
1000 and store timeout value in ms.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/626https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/730
(cherry picked from commit e300138892)
(cherry picked from commit f55eeff70a)
If previously the profile would track two addresses ("10.116.1.130/24",
"10.116.1.65/24"), and during an update the second address was removed
(leaving "10.116.1.130/24"), then the addresses of the profile were
wrongly not changed.
The effect is that removing a secondary IP address might not take
effect.
Fix that.
https://bugzilla.redhat.com/show_bug.cgi?id=1920838
Fixes: 69f048bf0c ('cloud-setup: add tool for automatic IP configuration in cloud')
(cherry picked from commit bbd36be44a)
(cherry picked from commit c861e87b7f)
The idea of NM_G_MUTEX_LOCKED() macro is not only to register a mutex
for unlocking (via nm_auto_unlock_g_mutex) but also to lock it at
the same time.
That is a useful helper macro. If you have to lock the mutex yourself,
it makes usage less convenient. At which point you don't need the macro
anymore and you should instead take full control and lock/unlock yourself.
Fix the macro and change behavior. The macro was not used so far, so
it's not a problem.
Fixes: dd33b3a14e ('shared: add nm_auto_unlock_g_mutex and NM_G_MUTEX_LOCKED() helper macros')
(cherry picked from commit 098ac7dbc0)
(cherry picked from commit 3c27a3ed5f)
(cherry picked from commit 4dfeec4eca)
Currently if we detect that a scan finished in
_scan_notify_is_scanning(), we call immediately _scan_kickoff() (which
might start a new scan) and then we check again whether the device can
autoactivate or whether to remove the wifi-scan pending action.
This means that if the scan takes long enough, when
_scan_notify_is_scanning() is called, it is already time to start
another scan and the device activation will be delayed. It will be
delayed until the scan duration becomes shorter than the
exponentially-growing periodic scan interval.
Fix this by delaying the next scan immediately after a scan result.
Co-authored-by: Thomas Haller <thaller@redhat.com>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/574
(cherry picked from commit 16d649ea92)
(cherry picked from commit 94044c7441)
We cannot drop the reference count to zero while having
no lock. Otherwise, another thread might race doing
s = nm_ref_string_new("...");
nm_ref_string_unref(s);
and already successfully delete the instance.
Hitting this race should be rather difficult, especially because
we tend to use NMRefString only from one thread. But still, access
to global variables must be race free.
Fixes: 908fadec96 ('shared: add NMRefString')
(cherry picked from commit 3490a09a7d)
(cherry picked from commit 1a68a54471)
GObject's dispose() functions may be called multiple times
to break reference cycles.
As dispose() calls _init_release_all(), the object might
already be partially destroyed.
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
(cherry picked from commit ef6edd8dbd)
(cherry picked from commit 9659db281f)
wpa_supplicant has a property "scanning" and a "state=scanning".
Previously, NetworkManager considered both parts to indicate whether
supplicant is currently scanning (if either the property or the state
indicated scanning, it took that as indication for scanning).
If NetworkManager thinks that supplicant is scanning, it suppresses
explicit "Scan" requests. That alone is not severe, because the "Scan"
request is only to trigger a scan in supplicant (which supplicant
possibly is already doing in state "scanning").
However, what is severe is that NetworkManager will also block autoconnect
while supplicant is scanning. That is because NetworkManager wants to get
a complete scan result before deciding which network to connect to.
It seems that wpa_supplicant can get into "state=scanning" and stay
there indefinitely. This prevents NetworkManager from autoactivating
a profile.
Fix that, to only honor the "scanning" property.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/597
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling')
(cherry picked from commit 8cadfed2fe)
(cherry picked from commit fbe6240a7d)
During shutdown, NM always tries to remove from ovsdb all bridges,
ports, interfaces that it previously added. Currently NM doesn't run
the main loop during shutdown and so it's not possible to perform
asynchronous operations. In particular, the NMOvsdb singleton is
disposed in a destructor where it's not possible to send out all the
queued deletions.
The result is that NM deletes only one OVS interface, keeping the
others. This needs to be fixed, but requires a rework of the shutdown
procedure that involves many parts of NM.
Even when a better shutdown procedure will be implemented, we should
support an unclean shutdown caused by e.g. a kernel panic or a NM
crash. In these cases, the interfaces added by NM would still linger
in the ovsdb.
Delete all those interface at NM startup. If there are connections
profiles for them, NM will create them again.
https://bugzilla.redhat.com/show_bug.cgi?id=1861296https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/700
(cherry picked from commit e5113a7fd9)
(cherry picked from commit 1125c5d3dd)
The parser checks if the first token of an ip= argument is an IP
address to determine which of the two possible syntaxes is used:
ip=<interface>:{dhcp|on|any|dhcp6|auto6}[:[<mtu>][:<macaddr>]]
ip=<client-IP>:[<peer>]:<gateway-IP>:<netmask>:<client_hostname>:<interface>:{none|off|dhcp|on|any|dhcp6|auto6|ibft}[:[<mtu>][:<macaddr>]]
This works as long as the first token is not empty, which - according
to the dracut.cmdline man page - seems to be guaranteed.
However, the network-legacy dracut plugin accepts an empty interface
or client IP. Also, if a user needs DHCP and wants to specify a
hostname, the only possible syntax is:
ip=::::<hostname>::dhcp
Change the parser to check the second token instead, similarly to what
the network-legacy module does [1].
[1] https://github.com/dracutdevs/dracut/blob/050/modules.d/40network/net-lib.sh#L490https://bugzilla.redhat.com/show_bug.cgi?id=1900260https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/693
(cherry picked from commit b0c018830e)
(cherry picked from commit 435d662669)
g_hash_table_iter_next() wants a (gpointer *), not an (int *).
Fixes: f70ee67058 ('dns: sd-resolved: reset interface configuration on deactivation')
(cherry picked from commit 526b484be1)
(cherry picked from commit dedcba61ef)
We now always use SetLinkDefaultRoute(), but that API was only added in
systemd v240 ([1]).
We could just always call the non-existing method, and ignore the
error. However, that feels ugly. Would systemd-resolved log warnings
about that? Should we suppress all messages about that failure (not
good for debugging).
Instead, make an effort to detect support of the function, and avoid
calling it. That is significantly more complicated than just always
calling the method and not care.
Note that even if systemd-resolved does not support SetLinkDefaultRoute(),
we cannot do anything smart about that. We would simply rely on
systemd-resolved (hopefully) doing the right thing automatically.
That's better and simpler than explicitly adding a "~." domain in
the fallback case.
Also, detecting support is straight forward in the common case, where
there is either success or a clear "org.freedesktop.DBus.Error.UnknownMethod"
error. In cases where there is any other failure, we don't really know.
In that case, we keep trying to use the API under the assumption that
it should work.
[1] https://github.com/systemd/systemd/commit/7 ## 7673795dcf5797491e7f785cbf5077d29a15db4
(cherry picked from commit 44ebb99cfa)
(cherry picked from commit c182984469)
(cherry picked from commit c469283893c82a10a31d3162e0e7e41258cd9ec8)
When the DNS settings change, we update the request_queue_lst_head list,
with all the requests we want to send.
Then, send_updates() will try to send it. It might not do it right away,
if resolved is not on the bus or the D-Bus connection is not fully inialized
(meaning, we don't know the name owner yet). In those cases, we would
keep the list of requests, and send them later.
However, when sending them, we would also forget about the configuration.
That means, if you restart systemd-resolved, then the daemon drops off
the bus and reappears. I think that systemd-resolved in fact persists
the configuration during restart. So, usually the settings are still the
same after restart. However, we should do better here: if the service
appears, we should send the settings again.
This means to not forget the requests after we send them once -- at
least, until a new update replaces them.
(cherry picked from commit 4fc44952f7)
(cherry picked from commit 3f16b988a4)
(cherry picked from commit cb8737e5a523838fe0bf53008a463d06836e6844)
We will need these changes next:
- add "self" and "ifindex" fields to RequestItem struct. We will
pass on these structs are user-data for the callbacks, so that
we afterwards know which request completed.
- add DBUS_OP_SET_LINK_DEFAULT_ROUTE global variable. We don't
clone the "operation" string but use string literals. However,
string literals are not guaranteed to be deduplicated, so we
should only compare them with strcmp(). The static variable
avoids this: we can use pointer equality to compare it.
This will be used next.
(cherry picked from commit 8af6647cda)
(cherry picked from commit 4401c6d567)
(cherry picked from commit 112d2714c393b56c6ab72e98548652725d458a48)
If the interface is the DNS default route but has no domain, its name
servers were not sent to systemd-resolved. Fix this.
Fixes: ee9fab0361 ('dns: fix handling default routing domains with systemd-resolved')
(cherry picked from commit 195cbf3cee)
(cherry picked from commit ae453f0ae8)
With glib2-2.67.0-1.fc34.x86_64.rpm, clang-11.0.0-2.fc34.x86_64.rpm, the
generated code emits a compiler warning:
libnm-core/tests/nm-core-tests-enum-types.c:17:7: error: passing 'typeof (*(&g_define_type_id__volatile)) *' (aka 'volatile unsigned long *') to parameter of type 'gsize *' (aka 'unsigned long *') discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
if (g_once_init_enter (&g_define_type_id__volatile))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gthread.h:260:7: note: expanded from macro 'g_once_init_enter'
(!g_atomic_pointer_get (location) && \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gatomic.h:112:38: note: expanded from macro 'g_atomic_pointer_get'
__atomic_load (gapg_temp_atomic, &gapg_temp_newval, __ATOMIC_SEQ_CST); \
^~~~~~~~~~~~~~~~~
libnm-core/tests/nm-core-tests-enum-types.c:40:7: error: passing 'typeof (*(&g_define_type_id__volatile)) *' (aka 'volatile unsigned long *') to parameter of type 'gsize *' (aka 'unsigned long *') discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
if (g_once_init_enter (&g_define_type_id__volatile))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gthread.h:260:7: note: expanded from macro 'g_once_init_enter'
(!g_atomic_pointer_get (location) && \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gatomic.h:112:38: note: expanded from macro 'g_atomic_pointer_get'
__atomic_load (gapg_temp_atomic, &gapg_temp_newval, __ATOMIC_SEQ_CST); \
^~~~~~~~~~~~~~~~~
libnm-core/tests/nm-core-tests-enum-types.c:63:7: error: passing 'typeof (*(&g_define_type_id__volatile)) *' (aka 'volatile unsigned long *') to parameter of type 'gsize *' (aka 'unsigned long *') discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
if (g_once_init_enter (&g_define_type_id__volatile))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gthread.h:260:7: note: expanded from macro 'g_once_init_enter'
(!g_atomic_pointer_get (location) && \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gatomic.h:112:38: note: expanded from macro 'g_atomic_pointer_get'
__atomic_load (gapg_temp_atomic, &gapg_temp_newval, __ATOMIC_SEQ_CST); \
^~~~~~~~~~~~~~~~~
We could pass "-Wincompatible-pointer-types-discards-qualifiers" as CFLAGS
when building this file. However, we have a workaround in our "nm-glib-aux/nm-glib.h",
so we can instead include "nm-default.h". At first glance, that might look like
the less preferable solution. However, this file is only there for unit tests,
and we also include "nm-default.h" for other sources that are generated with
"glib-mkenums". So, doing it also for our tests becomes the preferable solution.
(cherry picked from commit 755d97d38c)
(cherry picked from commit 294efba18f)
