g_random_*() is based on GRand, which is not a CSPRNG. Instead, rely on
kernel to give us good random numbers, which is what nm_random_*() does.
Note that nm_random_*() calls getrandom() (or reads /dev/urandom), which
most likely is slower than GRand. It doesn't matter for our uses though.
It is cumbersome to review all uses of g_rand_*() whether their usage of
a non-cryptographically secure generator is appropriate. Instead, just
always use an appropriate function, thereby avoiding this question. Even
glib documentation refers to reading "/dev/urandom" as alternative. Which
is what nm_random_*() does. These days, it seems unnecessary to not use
the best random generator available, unless it's not fast enough or you
need a stable/seedable stream of random numbers.
In particular in nmcli, we used g_random_int_range() to generate
passwords. That is not appropriate. Sure, it's *only* for the hotspot,
but still.
(cherry picked from commit 6e96d71731)
The compiler may dislike this:
CC src/core/platform/tests/libNetworkManagerTest_la-test-common.lo
In function '_ip_address_add',
inlined from 'nmtstp_ip4_address_add' at ../src/core/platform/tests/test-common.c:1892:5:
../src/core/platform/tests/test-common.c:1807:63: error: array subscript 'NMIPAddr {aka const struct _NMIPAddr}[0]' is partly outside array bounds of 'in_addr_t[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds]
1807 | peer_address->addr4,
| ~~~~~~~~~~~~^~~~~~~
../src/core/platform/tests/test-common.c: In function 'nmtstp_ip4_address_add':
../src/core/platform/tests/test-common.c:1886:36: note: object 'peer_address' of size 4
1886 | in_addr_t peer_address,
| ~~~~~~~~~~~~^~~~~~~~~~~~
...
Fixes: 06aafabf14 ('platform/test: add test adding IPv4 addresses that only differ by their peer-address')
(cherry picked from commit 40dd8bf93a)
When reloading the configuration and there is a global DNS
configuration without domains, NM crashes in global_dns_equal()
because `old->domains` and `new->domains` are both NULL. Fix that.
Thread 1 "NetworkManager" received signal SIGTRAP, Trace/breakpoint trap.
0 g_logv (log_domain=0x7fe81a2110be "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=<optimized out>) at ../glib/gmessages.c:1433
1 g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at ../glib/gmessages.c:1471
2 g_hash_table_size (hash_table=<optimized out>) at ../glib/ghash.c:2183
3 g_hash_table_size (hash_table=<optimized out>) at ../glib/ghash.c:2181
4 global_dns_equal (new=0xecc540, old=0xe618e0) at ../src/core/nm-config-data.c:1466
5 nm_config_data_diff (old_data=old_data@entry=0xe60020, new_data=new_data@entry=0xe606a0) at ../src/core/nm-config-data.c:1946
6 _set_config_data (self=0xe45810, new_data=0xe606a0, reload_flags=NM_CONFIG_CHANGE_CAUSE_SIGHUP) at ../src/core/nm-config.c:2923
7 nm_config_reload (self=0xe45810, reload_flags=NM_CONFIG_CHANGE_CAUSE_SIGHUP, emit_warnings=emit_warnings@entry=1) at ../src/core/nm-config.c:2875
8 nm_main_config_reload (signal=<optimized out>) at ../src/core/main.c:141
9 sighup_handler (user_data=<optimized out>) at ../src/core/main-utils.c:26
10 g_main_dispatch (context=0xe619e0) at ../glib/gmain.c:3444
11 g_main_context_dispatch (context=0xe619e0) at ../glib/gmain.c:4162
12 g_main_context_iterate.constprop.0 (context=0xe619e0, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4238
13 g_main_loop_run (loop=0xe5e310) at ../glib/gmain.c:4438
14 main (argc=<optimized out>, argv=<optimized out>) at ../src/core/main.c:515
Fixes: 1f0d1d78d2 ('dns-manager: always apply options from [global-dns]')
(cherry picked from commit ba4a9ea79a)
The global configuration now can be valid when there are no global
domains defined. The dnsmasq backend must process it and then, if
there is no global default domain, also process the per-connection
settings.
Fixes: 1f0d1d78d2 ('dns-manager: always apply options from [global-dns]')
(cherry picked from commit 5c0a927e0f)
We are passing to the plugin only 'sett_flags', which is the bitmask
of flags to change and works together with 'sett_mask'; however,
plugins interpret that value as the new flags value. The result is
that if there is no change needed (0/0), the existing flags are lost.
Simple reproducer:
ip link add dummy1 type dummy
ip link set dummy1 up
ip addr add dev dummy1 fd01::12/64
sleep 1
# now, a external connection is created by NM
echo "BEFORE:"
cat /run/NetworkManager/system-connections/dummy1.nmconnection | grep "nm-generated\|volatile\|external"
# just add a new address to the interface to make it lose
# the external flag
ip addr add dev dummy1 172.25.42.1/24
sleep 1
echo "AFTER:"
cat /run/NetworkManager/system-connections/dummy1.nmconnection | grep "nm-generated\|volatile\|external"
Output:
BEFORE:
nm-generated=true
volatile=true
external=true
AFTER:
Fixes: d35d3c468a ('settings: rework tracking settings connections and settings plugins')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1548
(cherry picked from commit 86b922695f)
To embrace the inclusive language, deprecate the NMActiveConnection
Master property and in favor of the NMActiveConnection Controller
property.
(cherry picked from commit af677542b5)
This setting allows the user to remove the local route rule that is
autogenerated for both IPv4 and IPv6. By default, NetworkManager won't
touch the local route rule.
(cherry picked from commit d2ca44ffc6)
A tentative IPv6 address can still fail DAD, so don't use it to
resolve the hostname via DNS. Furthermore, tentative addresses can't
be used to contact the nameserver and so the resolution will fail if
there is no other valid IPv6 address. Wait that the address becomes
non-tentative.
(cherry picked from commit 4138be6a5a)
Currently the only way to return an error code from the daemon helper
is via the process exit code, but that is not enough to fully describe
an error from getaddrinfo(); in fact, the function returns a EAI_*
error code and when the value is EAI_SYSTEM, the error code is
returned in errno.
At the moment, any messages printed to stderr by the helper goes to NM
stderr; instead, we want to capture it and pass it through the logging
mechanism of NM, so that it can be filtered according to level and
domain.
(cherry picked from commit d65702803c)
Improve logging:
- log only when something changes
- print the new resolver state, instead of the old one
- rename state "in-progress" to "started"
- log when the resolver state is reset due to DNS changes
(cherry picked from commit 7037aa66c6)
This is also the format that we will use to expose it in the lease
information. It's the format that dhclient uses.
(cherry picked from commit 2fe4313b92)
We already get the IAID from the dhclient environment. This is actually
rather useful, because dhclient plugin does not support setting the
value (that is, what we request in "config.v6.iaid" is not actually
used). Already previously, was the IAID for dhclient present in the
lease information. Now also normalize/verify it.
Expose the used IAID also with the internal (systemd) plugin. There we
explicitly set the IAID and know it.
(cherry picked from commit 07f1789725)
Our lease is tracked in a plain string dictionary. For dhclient plugin
and similar, the keys are received via the environment, they are thus
unlimited. For the internal plugins they are known at compile time and
static strings. We thus sometimes need to clone the string, and
sometimes not.
Unfortunately, we cannot ask the GHashTable whether it has a free
function for the key, so we need to explicitly tell it. Add a parameter
for that.
(cherry picked from commit 5a05ba398b)
There should be one function for parsing the string. Use it everywhere.
Also, because we will accept specifying the IAID as hex string so the
same parsing code should be used everywhere.
(cherry picked from commit 69106d0aef)
When a software device is deactivated, normally we schedule a idle
task to unrealize the device (delete_on_deactivate). However, if a new
activation is enqueued on the same device (and that implies that the
new profile is compatible with the device), then the idle task is not
scheduled and the device will normally transition to the different
states (disconnected, prepare, config, etc.).
For ovs-interfaces, we remove the db entry on disconnect and that
makes the link go away; however, we don't clear the hw_addr* fields of
the device struct.
When the new link appears, we try to set the new cloned MAC but the
stale hw_addr field indicates that it's already set. Avoid this
problem by updating the address as soon as the link appears.
https://bugzilla.redhat.com/show_bug.cgi?id=2168477https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1532
(cherry picked from commit d403ac3d40)
- Only consider preferred context of "internet" type. There can be
multiple preferred contexts of multiple types, and we care about
"internet" type only.
- Don't check for "internet+mms" type. It turns out that "internet+mms"
isn't a thing in oFono, and is used to represent "internet" context
with MMSC in the lomiri-system-setting's UI only.
Fixes: 9fc72bf75d ('wwan/ofono: create connections based on available contexts')
Bug-UBports: https://gitlab.com/ubports/development/core/packaging/network-manager/-/issues/3
(cherry picked from commit 08a38ed619)
Trigger a dispatcher event when a connection is reapplied on a NM device.
Some devices such as phones have already a DHCP client running for accepting
connections when they are plugged into USB to transfer data over SSH.
When NetworkManager switches the connection IP method to shared,
it spawns a dnsmasq process to handle DHCP and DNS for that connection.
However, a dispatcher event is needed to disable the external DHCP server
for these USB connections as NetworkManager's dnsmasq handles them now.
Moreover, when the connection method is switched to a different mode,
the external DHCP server needs to be spawned again to make sure that
SSH connections are still possible to the device.
To achieve this, add a new NetworkManager Dispatcher event
'reapply' which is triggered when a connection is reapplied on a NM
device. This way, a dispatcher script can handle the case above by
inspecting the IP method in the dispatcher script.
(cherry picked from commit cef880c66f)
The onlink flag is part of each next hop.
When NetworkManager configures ECMP routes, we won't support that. All
next hops of an ECMP route must share the same onlink flag. That is fine
and fixed by this commit.
What is not fine, is that we don't track the rtnh_flags flags in
NMPlatformIP4RtNextHop, and consequently our nmp_object_id_cmp() is
wrong.
Fixes: 5b5ce42682 ('nm-netns: track ECMP routes')
(cherry picked from commit 6ed966258c)
If the route with a next hop is already onlink, we don't need to add a
direct route to the gateway.
It also wouldn't work previously, because the onlink route to the
gateway that we would add, would have no gateway and the RTNH_F_ONLINK
set. Kernel would reject that with an error. We would have to clear the
RTNH_F_ONLINK flag, if there is no gateway.
(cherry picked from commit 93b46c8906)
The dns-type must be included in the hash because it contributes to
the generated composite configuration. Without this, when the type of
a configuration changes (e.g. from DEFAULT to BEST), the DNS manager
would determine that there was no change and it wouldn't call
update_dns().
https://bugzilla.redhat.com/show_bug.cgi?id=2161957
Fixes: 8995d44a0b ('core: compare the DNS configurations before updating DNS')
(cherry picked from commit 46ccc82a81)
The tests failed in certain cases on gitlab-ci and were temporarily
disabled.
These issues should be fixed now and the test pass. Reenable.
(cherry picked from commit 5c324adc7c)
Kernel enforces that all nexthops must be reachable through a route.
L3Cfg is generating dependent onlink routes to solve this problem but
the IPv4 ECMP commit is happening before that.
To solve this we introduce two boolean fields "is_new" and "is_ready" to
know in which state is the L3Cfg affected. Initially, "is_new" is TRUE
and "is_ready" is FALSE. Here we schedule a commit on idle and we set
"is_new" to FALSE. When revisiting, we set "is_ready" to TRUE and then
we set the ECMP IPv4 routes.
When a reapply kicks in we reset the L3Cfg state by setting "is_new" to
TRUE.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1520
(cherry picked from commit 7a844ecba9)
Kernel enforces that all route nexthop are reachable but it doesn't care
if the drect route to the nexthop is in a different route table.
(cherry picked from commit f187e63fa8)
ECMP IPv4 route nexthops requires an onlink route but we should trust
l3cfg when generating and managing such routes.
This reverts commit 737cb5d424.
(cherry picked from commit cbf70b4dca)
We must trust l3cfg when generating dependent onlink routes for all kind
of routes not default routes only. This was done by
"nm_platform_ip_route_sync()" so there is not change in behaviour at
all.
"nm_platform_ip_route_sync()" could be needed for other situation where
l3cfg cannot add the dependent onlink routes, so we are not removing
that logic.
This reverts commit 6b4123db1c.
(cherry picked from commit 9c492c6fc4)
Certain ip-tunnel modules automatically create network interfaces (for
example, "ip_gre" module creates "gre0" and others).
Btw, that's not the same as `modprobe bonding max_bonds=1`, where
loading the module merely automatically creates a "bond0" interface. In
case of ip tunnel modules, these generated interfaces seem essential to
how the tunnel works, for example they cannot be deleted. I don't
understand the purpose of those interfaces, but they seem not just
regular tunnel interfaces (unlike, "bond0" which is a regular bond
interface, albeit automatically created).
Btw, if at the time when loading the module, an interface with such name
already exists, it will bump the name (for example, adding a "gre1"
interfaces, and so on). That adds to the ugliness of the whole thing,
but for our unit tests, that is no problem. Our unit tests run in a
separate netns, and we don't create conflicting interfaces. That is, an
interface named "gre0" is always the special tunnel interface and we
can/do rely on that.
Note that when the kernel module gets loaded, it adds those interfaces
to all netns. Thus, even if "test-route-linux" does not do anything with
ip tunnels, such an interface can always appear in a netns, simply by
running "test-link-linux" (or any other tool that creates a tunnel) in
parallel or even in another container.
Theoretically, we could just ensure that we load all the conflicting
ip-tunnel modules (with nmtstp_ensure_module()). There there are two
problems. First, there might be other tunnel modules that interfere but
are not covered by nmtstp_ensure_module(). Second, when kernel creates
those interfaces, it does not send correct RTM_NEWLINK notifications (a
bug), so our platform cache will not be correct, and
nmtstp_assert_platform() will fail.
The only solution is to detect and ignore those interfaces. Also,
ignore all interfaces of link-type "unknown". Those might be from other
modules that we don't know about and that exhibit the same problem.
(cherry picked from commit e99433866d)
Ubuntu 18.04 comes with iproute2-4.15.0-2ubuntu1.3. The
"/etc/iproute2/rt_protos" file from that version does not yet support
the "bgp" entry. Also the "babel" entry is only from 2014. Just choose
other entries. The point is that NetworkManager would ignore those, and
that applies to "zebra" and "bird" alike.
(cherry picked from commit 26592ebfe5)
This will make sure that the IP tunnel module is loaded. It does so by
creating (and deleting) a tunnel interface.
That is important, because those modules will create additional interfaces
that show up in `ip link` (like "gre0"), and those interfaces can interfere
with the tests.
Also add nmtstp_link_is_iptunnel_special() to detect whether an
interface is one of those special interfaces.
(cherry picked from commit 451cedf2bf)
Seems this test fails easily under gitlab-ci, if we set NMTST_SEED_RAND
to something else than "0". There is nothing particular special about
"0", except that a randomly different code paths are chosen.
A randomized test that doesn't pass on all systems with all random
paths, is broken. Disable for now. Needs to be fixed.
See-also: https://bugzilla.redhat.com/show_bug.cgi?id=2165141
(cherry picked from commit 14b1a7ba30)
Obviously, it would be nice if our unit tests are fast. However, with
valgrind and a busy machine, some of the tests can take a relatively
long time. In particular those, that are marked as "slow" (if you want
to skip them during development, do so via "NMTST_DEBUG=quick"
environment, or "CFLAGS=-DNMTST_TEST_QUICK=TRUE", see
"nm-test-utils.h").
Anyway. Our tests almost never hit the timeout, and if they do, the most
likely reason is that something was just slower then expected, and the
timeout is a bogus error.
Timeouts only act as last fail safe. It more important to avoid a false
(premature) timeout failure, than to minimize the wait time when the
test really hangs. Because a real hang is a bug anyway, that we will
discover and need to fix.
Increase the default test timeout for meson tests to 3 minutes.
Also, "test-route-linux" is known to take a long time. Increase that
timeout even further.
(cherry picked from commit 9ee42c0979)
Currently, the use of [global-dns] section for setting DNS options is
conditioned on presence of a nameserver in a [global-dns-domain-*] section.
Attempt to use the section for options alone results in an error:
[global-dns]
options=timeout:1
Or via D-Bus API:
# busctl set-property org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager org.freedesktop.NetworkManager \
GlobalDnsConfiguration 'a{sv}' 2 \
"options" as 1 "timeout:1" \
"domains" a{sv} 0
...
Nov 24 13:15:21 zmok.local NetworkManager[501184]: <debug> [1669292121.3904]
manager: set global DNS failed with error: Global
DNS configuration is missing the default domain
The insistence on existence of [global-dns-domain-*] would make sense if
other [global-dns-domain-...] sections were present.
However, the user might only want to set the options in resolv.conf and
still use connection-provide nameservers for the actual resolving.
Lift the limitation by allowing the [global-dns] to be used alone, while
still insist on [global-dns-domain-*] being there in presence of other
domain-specific options.
https://bugzilla.redhat.com/show_bug.cgi?id=2019306
(cherry picked from commit 1f0d1d78d2)
