This message is useless for non-interactive use and clobbers over
otherwise very appealing test output.
The callers knows what we're going to listen on, it passed us the file
descriptor.
Right now, on any baremetal only max. 2 physical NICs are available.
This might change in the future, so better to directly accept larger
nicIndex if we receive it. No behaviour change with this, just remove
an artificial limit.
.get_config_data is only alive while the get_config task is running. We
can't reach into it afterwards.
==92303== Invalid read of size 8
==92303== at 0x41247D: _iface_data_free (nmcs-provider.c:228)
==92303== by 0x4CB33C1: ??? (in /usr/lib64/libglib-2.0.so.0.6800.4)
==92303== by 0x4CB8082: g_hash_table_unref (in /usr/lib64/libglib-2.0.so.0.6800.4)
==92303== by 0x412425: nm_g_hash_table_unref (nm-shared-utils.h:2171)
==92303== by 0x412425: nmcs_provider_get_config_result_free (nmcs-provider.c:133)
==92303== by 0x407871: main (main.c:995)
==92303== Address 0x63b63f8 is 8 bytes inside a block of size 64 free'd
==92303== at 0x4847B4C: free (vg_replace_malloc.c:989)
==92303== by 0x4CCB76C: g_free (in /usr/lib64/libglib-2.0.so.0.6800.4)
==92303== by 0x4CE81DF: g_slice_free1 (in /usr/lib64/libglib-2.0.so.0.6800.4)
==92303== by 0x411C7B: _get_config_done_cb (nmcs-provider-oci.c:247)
==92303== by 0x4AF2489: ??? (in /usr/lib64/libgio-2.0.so.0.6800.4)
==92303== by 0x4AF268A: ??? (in /usr/lib64/libgio-2.0.so.0.6800.4)
==92303== by 0x40A91C: _poll_req_done_cb (nm-http-client.c:529)
==92303== by 0x4AF2489: ??? (in /usr/lib64/libgio-2.0.so.0.6800.4)
==92303== by 0x4AF268A: ??? (in /usr/lib64/libgio-2.0.so.0.6800.4)
==92303== by 0x415381: _poll_return (nm-shared-utils.c:7174)
==92303== by 0x416D97: _poll_done_cb (nm-shared-utils.c:7201)
==92303== by 0x4AF2489: ??? (in /usr/lib64/libgio-2.0.so.0.6800.4)
==92303== Block was alloc'd at
==92303== at 0x484482F: malloc (vg_replace_malloc.c:446)
==92303== by 0x4CCEB88: g_malloc (in /usr/lib64/libglib-2.0.so.0.6800.4)
==92303== by 0x4CE8C64: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.6800.4)
==92303== by 0x413113: nmcs_provider_get_config (nmcs-provider.c:304)
==92303== by 0x4076BD: _get_config (main.c:359)
==92303== by 0x4076BD: main (main.c:985)
There is no need to avoid including the full header, they are small
headers with some GLib type system stuff and no more. Just include them
where they are needed.
If we try to normalize a connection, we generally rely on it being
already valid and be normalized afterwards.
There's one particular case (nmcli interactive add/edit), where we call
it repeatedly on a best-effort basis and don't care about the failures.
Disable the warning there.
Completion of a connection must always result in a valid connection and
the call to normalize() is always expected to succeed here.
Croak if it doesn't because the rest basically relies on the connection
being normalized. If it's not valid, and can't be normalized, it's a bug.
The caller normalizes connections before spitting them out. On top of it
it actually handles the errors.
Rename the routine accordingly.
XXX FIXME test botched
All of these are wrong asserting that a connection has a particular
setting. On AddAndActivate, the connection can be pretty much empty:
impl_manager_add_and_activate_connection ()
validate_activation_request ()
nm_manager_get_best_device_for_connection ()
iface = nm_manager_get_connection_iface ()
find_parent_device_for_connection ()
nm_device_factory_get_connection_parent () <====== *shriek*
nm_device_factory_get_connection_iface ()
find_device_by_iface (iface)
nm_device_complete_connection ()
Remove those assertions.
Some of them are wrong: they assert a connection has a particular
setting even though this can be called on AddAndActivate against a
connection that is not complete or normalized:
impl_manager_add_and_activate_connection ()
validate_activation_request ()
nm_manager_get_best_device_for_connection ()
iface = nm_manager_get_connection_iface ()
find_parent_device_for_connection ()
nm_device_factory_get_connection_parent ()
nm_device_factory_get_connection_iface () <====== here
find_device_by_iface (iface)
nm_device_complete_connection ()
Fix those by removing the assertions.
Some of them are also fall back to just calling
nm_connection_get_interface_name() which is a pretty useless thing to do
because nm_device_factory_get_connection_iface() only calls the
device-specific routine if nm_device_factory_get_connection_iface()
doesn't return anything, to give the factory a chance to make up a name
(like <parent>.<vlan-id> for Vlan) on its own. Drop those.
It attempts to modify attributes clearly belong to TestNmcli such as
_skip_test_for_l10n_diff or call methods that are in unittest.TestCase:
======================================================================
ERROR: test_002 (__main__.TestNmcli.test_002)
----------------------------------------------------------------------
Traceback (most recent call last):
File ".../src/tests/client/test-client.py", line 1508, in f
self.ctx.run_post()
~~~~~~~~~~~~~~~~~^^
File ".../src/tests/client/test-client.py", line 1185, in run_post
self.fail(
^^^^^^^^^
AttributeError: 'NMTestContext' object has no attribute 'fail'
It has presumably been moved out of TestNmcli at some point, but that
seems to have been in error, as it's also pretty specific to the nmcli
test cases. Not useful for cloud-init tests that also utilize
NMTestContext. Move it back.
We always sync routes in the main table, but routes in tables other
than main are only pruned if were added by NM, by default. Get the list
of routes to prune from other tables using obj_state->os_nm_configured,
as this tracks what routes were effectively added by NM.
The list should be the same that the one obtained from l3cfg_old. It
could be different if we commited the l3cfg with an NMIPRouteTableSyncMode
of NM_IP_ROUTE_TABLE_SYNC_MODE_MAIN, thus not deleting some routes at
commit time. However, since the previous commit, we never do it.
What all this shows is that starting to use different NMIPRouteTableSyncModes
is probably a bad idea: it will be a source of bugs of routes not being
always synced as users expect, and the use case for them is still to be
known.
By default, on reapply we were only syncing the main routes table. This
causes that routes added by NM to other tables are not removed on
reapply. This was done to preserve routes added externally, but routes
added by NM itself should be removed.
Add a new route table syncing mode "main + NM routes". This mode
maintains the normal behaviour of syncing completely the main table,
and for other tables removes only routes that were added by us, leaving
the rest untouched. Use this mode by default, as this is what a user
would expect on reapply.
Note: this might not work if NM is restarted between the profile being
modified and the reapply, because NM forgets what routes were added by
itself because of the restart. This is a rare corner case, though.
Use the D-Bus property "VersionInfo" to expose a capability flag
indicating that this bug is fixed. It is the first capability that we
expose in this way. However, it is convenient to do it this way as it's
something that clients like nmstate needs to know, so they can decide
whether a conn down is needed or not. It is not enough to decide that by
version number because it might be fixed via a downstream patch in distros
like RHEL.
https://issues.redhat.com/browse/RHEL-67324https://issues.redhat.com/browse/RHEL-66262
Fixes: e9c17fcc9b ('l3cfg: default to 'main' route table sync mode')
The difference between FULL and ALL was not obvious without reading the
documentation. Moreover, a new mode is going to be introduced so the
confusion could grow. Rename to a more explicit name.
Remove the `+ 31u` that was making that it would search for bit 1 at
array's element 1, instead of element 0. Fixed comparison >len that
shoudl be >=len. Fix a few typos.
Fixes: bc6098d441 ('libnm: add internal nmc_client_has_{version_info_v,version_info_capability,capability}() helper')
when the kernel boot parameter ipv6.disable=1 is set, NetworkManager
attempts to read files under /proc/sys/net/ipv6, resulting in numerous
error messages in the debug logs. For example:
NetworkManager[758]: <debug> [1726699000.9384] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/disable_ipv6: Failed to open file "/proc/sys/net/ipv6/conf/lo/disable_ipv6": No such file or directory
NetworkManager[758]: <debug> [1726699000.9400] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/accept_ra: Failed to open file "/proc/sys/net/ipv6/conf/lo/accept_ra": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/disable_ipv6: Failed to open file "/proc/sys/net/ipv6/conf/lo/disable_ipv6": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/hop_limit: Failed to open file "/proc/sys/net/ipv6/conf/lo/hop_limit": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/use_tempaddr: Failed to open file "/proc/sys/net/ipv6/conf/lo/use_tempaddr": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/temp_valid_lft: Failed to open file "/proc/sys/net/ipv6/conf/lo/temp_valid_lft": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/temp_prefered_lft: Failed to open file "/proc/sys/net/ipv6/conf/lo/temp_prefered_lft": No such file or directory
...
This also results unnecessary system calls by attempting to open non-existent sysfs.
This patch adds checks in some ipv6 sysctl functions to verify the existence of /proc/sys/net/ipv6.
While there are still other paths that attempts to open IPv6 sysfs, this
eliminates many reading errors.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2040
RFC 4191 section-3.1 says:
When processing a Router Advertisement, a type C host first updates a
::/0 route based on the Router Lifetime and Default Router Preference
in the Router Advertisement message header. [...] The Router Preference
and Lifetime values in a ::/0 Route Information Option override the
preference and lifetime values in the Router Advertisement header.
Fix the RA parsing so that the parameters from a default route option
are applied to the gateway.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1666https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2072
Fixes: c3a4656a68 ('rdisc: libndp implementation')
The keyfile format allows to specify the gateway in two ways: with a
separate "gateway" key, or by appending the gateway address to one of
the address$N lines:
[ipv4]
address1=192.0.2.1/24
gateway=192.0.2.254
[ipv4]
address1=192.0.2.1/24,192.0.2.254
The former syntax is self-documenting and easier to understand for
users, but NetworkManager defaults to the latter when writing
connection files, for historical reasons. Change that and use the
explicit form.
Note that if a users has scripts manually parsing keyfiles, they could
stop working and so this can be considered an API breakage. OTOH,
those scripts are buggy if they don't support both forms, and they can
already break with perfectly valid user-generated keyfiles.
I think it's acceptable to change the default way to persist keyfiles;
the only precaution would be that this patch should not be applied
during a stable release cycle of a distro.
We already check that a connection doesn't not change when it's
written and re-read from disk. Add another check to verify that the
generated keyfile matches a static one, so that we don't introduce
unwanted changes. The reference keyfiles can be generated by running
the test with "NM_TEST_REGENERATE=1".
The "closure" annotation needs to be set on the callback parameter
instead of on the data for the callback function.
This patch fixes the following warning:
"""
../src/libnm-core-impl/nm-utils.c:3632: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:4778: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:5776: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:5849: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:5976: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6091: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6448: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6521: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6581: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6663: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-client.c:6728: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:974: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:1014: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:1041: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:974: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:1014: Warning: NM: invalid "closure" annotation: only valid on callback parameters
../src/libnm-client-impl/nm-secret-agent-old.c:1041: Warning: NM: invalid "closure" annotation: only valid on callback parameters
"""
Calling c_list_link_tail() on a list entry that already belongs to
another list corrupts the other list, in this case 'old_lst_head';
this is explained in the documentation of c_list_link_before():
* @what is not inspected prior to being linked. Hence, it better not
* be linked into another list, or the other list will be corrupted.
This can be reproduced by invoking "nmcli device wifi rescan ssid x"
multiple times; in this way, _scan_request_ssids_track() reuses the
previous SSID data, the list gets corrupted and this causes a crash.
Fixes: 7500e90b53 ('wifi: rework scanning of Wi-Fi device')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2076
After upgrading to RHEL-9.4, customers have reported that `ip monitor`
repeatedly logs the same route additions every 30 seconds. This issue
appears to stem from NetworkManager continually retrying to add the same
routes due to keep retrying Address Conflict Detection (ACD) on NOARP
interfaces.
To prevent unnecessary route additions and reduce log noise, this change
modifies NetworkManager's behavior to stop retrying ACD on interfaces
with the NOARP flag.
This fix addresses route instability and excessive logging for affected
NOARP configurations.
https://issues.redhat.com/browse/RHEL-59125
