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)
(cherry picked from commit 0ebd753819)
Print errors from getaddrinfo() to stderr so that they will be logged
by NM.
(cherry picked from commit ac5325e96b)
(cherry picked from commit 41cd94f46a)
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)
(cherry picked from commit f1f1aee711)
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)
(cherry picked from commit 7e3dccb781)
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)
(cherry picked from commit 657949eacd)
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)
(cherry picked from commit 2e0e38ab17)
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)
(cherry picked from commit 6e80a19059)
dhclient exports the currently used IAID in the environment as
hex string. We expose this environment in our API, so this is also
the format that NetworkManager uses.
Accept setting the ipv[46].dhcp-iaid as hex string, so that the same
format is accepted on the profile.
While at it, also accept a hex number (0x) because it is also
convenient, and this change already introduces the precedent that the
IAID string is not unique/normalized.
(cherry picked from commit e5dc489197)
(cherry picked from commit 0b4446e252)
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)
(cherry picked from commit 99825e727b)
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)
(cherry picked from commit b87fa496ce)
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)
(cherry picked from commit 2a0f41af03)
The function operates on a NML3ConfigData, rename it and move it to
the right place.
(cherry picked from commit ec0a83b224)
(cherry picked from commit a7412e2c65)
nm_l3_config_data_get_nameservers() returns an array of in_addr_t or
struct in6_addr. This is not a string list.
Incidentally, it was still used correctly, using nm_ip_addr_from_packed_array().
Fix the code to use the right type. Also, only call g_checksum_update()
once for the packed array. No need to iterate over the list one by one.
Fixes: 8995d44a0b ('core: compare the DNS configurations before updating DNS')
The idea of nm_free_secret() is to clear the secrets from memory. That
surely is some layer of extra snake oil, because we tend to pass secrets
via D-Bus, where the memory gets passed down to (D-Bus) libraries which
have no idea to keep it private. Still...
But turns out, malloc_usable_size() might not actually be usable for
this. Read the discussion at [1].
Stop using malloc_usable_size(), which seems unfortunate.
There is probably no secret relevant data after the NUL byte anyway,
because we tend to create such strings once, and don't rewrite/truncate
them afterwards (which would leave secrets behind as garbage).
Note that systemd's erase_and_free() still uses malloc_usable_size()
([2]) but the macro foo to get that right is terrifying ([3]).
[1] https://github.com/systemd/systemd/issues/22801#issuecomment-1343041481
[2] 11c0f0659e/src/basic/memory-util.h (L101)
[3] 7929e180aa
Fixes: d63cd26e60 ('shared: improve nm_free_secret() to clear entire memory buffer')
(cherry picked from commit 8b66865a88)
(cherry picked from commit 6e7fb78b18)
Since glib 2.45, we are guaranteed that g_free() just calls free(), so
both can be used interchangeably. However, we still only depend on glib
2.40.
In any case, it's ugly to mix the two. Memory allocated by plain
malloc(), should be only freed with free(). The buffer in question comes
from readline, which allocates it using the system allocator.
Fixes: 995229181c ('cli: remove editor thread')
(cherry picked from commit 5dc07174d3)
(cherry picked from commit 633c734255)
Such leaks show up in valgrind, and are simply bugs.
Also, various callers (not all of them, which is another bug!) like to
take ownership of the returned string and free it. That means, we leave
a dangling pointer in the global variable, which is very ugly and error
prone.
Also, the callers like to free the string with g_free(), which is not
appropriate for the "rl_string" memory which was allocated by readline.
It must be freed with free(). Avoid that, by cloning the string using
the glib allocator.
Fixes: 995229181c ('cli: remove editor thread')
(cherry picked from commit 89734c7553)
(cherry picked from commit de87340b2f)
Sometimes the buffer space of the netlink socket runs out and we lose
the response to our link change:
<info> [1670321010.2952] platform-linux: netlink[rtnl]: read: too many netlink events. Need to resynchronize platform cache
<warn> [1670321010.3467] platform-linux: do-change-link[2]: failure changing link: internal failure 3
With 3 above being WAIT_FOR_NL_RESPONSE_RESULT_FAILED_RESYNC.
Let's try harder.
https://bugzilla.redhat.com/show_bug.cgi?id=2154350
(cherry picked from commit b8738002ed)
This is not nice:
<warn> [1670321010.3467] platform-linux: do-change-link[2]: failure changing link: internal failure 3
Let's explain what "internal failure 3" is.
(cherry picked from commit 1e6fd1288d)
Doing an "update" is wrong, because that will replace all "other_config"
entries. We only want to reset the "hwaddr".
Note that https://www.rfc-editor.org/rfc/rfc7047 says about
"<mutations>":
If <mutator> is "insert", then each of the key-value pairs in
the map in <value> is added to <column> only if its key is not
already present. The required type of <value> is slightly
relaxed, in that it may have fewer than the minimum number of
elements specified by the column's type.
That means, we need to first delete, and then insert the key.
Fixes: 5d4c8521a3 ('ovs: set MAC address on the bridge for local interfaces')
(cherry picked from commit 2641af2cc9)
"mutate" with operation "insert" does not update existing entries.
Delete them first.
Otherwise, a reapply that only change the value of an external-ids
entry does not work.
Note that https://www.rfc-editor.org/rfc/rfc7047 says about
"<mutations>":
If <mutator> is "insert", then each of the key-value pairs in
the map in <value> is added to <column> only if its key is not
already present. The required type of <value> is slightly
relaxed, in that it may have fewer than the minimum number of
elements specified by the column's type.
Fixes: 7055539c9f ('core/ovs: support setting OVS external-ids')
(cherry picked from commit d219527dba)
There are two callers of available_connections_add(). One from
cp_connection_added_or_updated() (which is when a connection
gets added/modified) and one from nm_device_recheck_available_connections().
They both call first nm_device_check_connection_available() to see
whether the profile is available on the device. They certainly
need to pass the same check flags, otherwise a profile might
be available in some cases, and not in others.
I didn't actually test this, but I think this could result
in a profile wrongly not being listed as an available-connection.
Moreover, that might mean, that `nmcli connection up $PROFILE`
might work to find the device/profile, but `nmcli device up $DEVICE`
couldn't find the suitable profile (because the latter calls
nm_device_get_best_connection(), which iterates the
available-connections). I didn't test this, because regardless of
that, it seems obvious that the conditions for when we call
available_connections_add() must be the same from both places.
So the only question is what is the right condition, and it would
seem that _NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST is the right
flag.
Fixes: 02dbe670ca ('device: for available connections check whether they are available for user-request')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1496
(cherry picked from commit 7af9562f28)
CURLOPT_PROTOCOLS [0] was deprecated in libcurl 7.85.0 with
CURLOPT_PROTOCOLS_STR [1] as a replacement.
Well, technically it was only deprecated in 7.87.0, and retroactively
marked as deprecated since 7.85.0 [2]. But CURLOPT_PROTOCOLS_STR exists
since 7.85.0, so that's what we want to use.
This causes compiler warnings and build errors:
../src/core/nm-connectivity.c: In function 'do_curl_request':
../src/core/nm-connectivity.c:770:5: error: 'CURLOPT_PROTOCOLS' is deprecated: since 7.85.0. Use CURLOPT_PROTOCOLS_STR [-Werror=deprecated-declarations]
770 | curl_easy_setopt(ehandle, CURLOPT_PROTOCOLS, CURLPROTO_HTTP | CURLPROTO_HTTPS);
| ^~~~~~~~~~~~~~~~
In file included from ../src/core/nm-connectivity.c:13:
/usr/include/curl/curl.h:1749:3: note: declared here
1749 | CURLOPTDEPRECATED(CURLOPT_PROTOCOLS, CURLOPTTYPE_LONG, 181,
| ^~~~~~~~~~~~~~~~~
This patch is largely taken from systemd patch [2].
Based-on-patch-by: Frantisek Sumsal <frantisek@sumsal.cz>
[0] https://curl.se/libcurl/c/CURLOPT_PROTOCOLS.html
[1] https://curl.se/libcurl/c/CURLOPT_PROTOCOLS_STR.html
[2] 6967571bf2
[3] e61a4c0b7c
Fixes: 7a1734926a ('connectivity,cloud-setup: restrict curl protocols to HTTP and HTTPS')
(cherry picked from commit dabfea2fc2)
The route table is part of the weak-id. You can see that with:
ip route replace unicast 1.2.3.4/32 dev eth0 table 57
ip route replace unicast 1.2.3.4/32 dev eth0 table 58
afterwards, `ip route show table all` will list both routes. The replace
operation is only per-table. Note that NMP_CACHE_ID_TYPE_ROUTES_BY_WEAK_ID
already got this right.
Fixes: 10ac675299 ('platform: add support for routing tables to platform cache')
(cherry picked from commit a3cea7f6fb)
This effectively makes [*global-dns-domain-*] sections in configuration be
ignored unless [*global-dns] is also present. This happens because
nm_config_keyfile_has_global_dns_config() mixes the group names up and
attempts to loop up [.intern.global-dns-domain-*] in user configuration and
[global-dns-domain-*] in the internal one.
Fixes: da0ded4927 ('config: drop global-dns.enable option in favor of .config.enable')
(cherry picked from commit de1c06daab)
(cherry picked from commit bd4f5333e8)
iptables takes a file lock at /run/xtables.lock. By default, if
the file is locked, iptables will fail with error. When that happens,
the iptables rules won't be configured, and the shared mode
(for which we use iptables) will not be setup properly.
Instead, pass "--wait 2", to block. Yes, it's ugly that we use
blocking program invocations, but that's how it is. Also, iptables
should be fast to not be a problem in practice.
(cherry picked from commit 84a71771d9)
No need to redundantly specify the path. Also, next we will specify the
"--wait" option, so this will work better.
(cherry picked from commit 53422c8693)
New files must be written to the build directory, not to the source
one.
Fixes: 5ee2f3d1dc ('dhcp/tests: refactor tests for nm_dhcp_dhclient_save_duid()')
(cherry picked from commit 2c056cf9a3)
This adjusts the change from commit ffbcf01589 ('test-ndisc-fake:
free l3cfg after creating fake-ndisc').
ndisc_new() already correctly handles the reference count of l3cfg via
"gs_unref_object". The party that took the wrong reference was
nm_fake_ndisc_new().
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
(cherry picked from commit da371f8108)
src/nmcli/devices.c:1196: double_free: Calling "_nm_auto_strfreev" frees pointer "arg_arr" which has already been freed.
Fixes: c5d45848dd ('cli: mark argv argument for command line parsing as const')
(cherry picked from commit a39ec8ca75)
With multi-connect enabled, this can cause infinite retries to autoconnect,
see [1].
That has bad consequences for example in initrd, where
nm-wait-online-initrd.service would wait up to one hour before failing
and blocking boot.
This reverts commit 1656d82045.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2039734#c5
Fixes: 1656d82045 ('policy: track the autoconnect retries in devices for multi-connect')
(cherry picked from commit aec7ae8279)
The label "try_again" is only reached by one goto. So it was correct
and sufficient to reset the state only there.
It is still error prone. The slighlty clearer approach is to clear
the state at each begin of the "try_again" step.
There should be no change in behavior.
I didn't confirm, but an optimizing compiler should (could) be able
to see that the cleanup is only necessary on retry, and generate the
same code as before. In any case, we should write code that is easier
to read, not optimize for something that a compiler should be able to
optimize itself.
(cherry picked from commit 911b550140)
There should be no change in behavior, but this way seems nicer.
Now _nmc_mangle_connection() doesn't return FALSE, it always
will try to mangle the connection and requires the caller to
first check whether that is appropriate.
Just move some code outside of _nmc_mangle_connection() and let
the caller check for the skip first.
The point is consistency, as the caller already does some checks to
whether skip the reapply. So it should do all the checks, so that
"mangle" never fails/skips.
(cherry picked from commit bbd32fba15)
Externally added IP addresses/routes should be preserved by
nm-cloud-setup. This allows other tools to also configure the interface
and the Reapply() call from nm-cloud-setup would not interfere
with those tools.
https://bugzilla.redhat.com/show_bug.cgi?id=2132754
(cherry picked from commit 29b0420be7)
Reapply() is supposed to make sure that the system (the interface)
is configured as indicated by the applied-connection. That means,
it will remove/add configuration to make the system match the requested
configuration.
Add a flag "preserve-external-ip" which relaxes this. During reapply,
IP addresses/routes that exist on the interface and which are not known
(or added) by NetworkManager will be left alone.
This will be used by nm-cloud-setup, so that it can reconfigure the
interface in a less destructive way, which does not conflict with
external `ip addr/route` calls.
Note that the previous commit just adds "VersionInfo" and the
possibility to expose capabilities (patch-level). This is not used
for the new reapply flag, because, while we might backport the
reapply flag, we won't backport the "VersionInfo" property. Exposing
new capabilities via the "VersionInfo" property will only become useful
in the future, where we can backport a capability to older NM versions
(but those that have "VersionInfo" too).
(cherry picked from commit 2c1fb50fb5)
