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 the connection didn't exist in advance, there's no unrealized device,
and find_device_by_iface() is not going to get us one.
Call system_create_virtual_device() afrer nm_utils_complete_generic()
completes the connection for virtual devices. Make sure we do proper
cleanup if we happen to fail the activation later, so that de device
doesn't end up hanging there.
Make validate_activation_request() only do the validation -- split the
determination of the device into find_device_for_activation().
The point of this is to be able complete the connection and actually
create a virtual device after the validation.
I believe this is also somewhat easier to follow now that the procedure
does what its name says.
The point is to get rid of device/connection type specific arguments, to
eventually be able to complete the connection on AddAndActivate before knowing
which factory is going to take care of creating the device.
Aside from that, the whole thing is pretty awful -- with complicated
macros and variadic argument (ugh). Let's get rid of that.
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.
Old branches tend to be formatted with a different versions of
clang-format, so when patches are backported, they introduce some
differences in formatting, making the check-tree job to fail.
These changes in formatting are normally small, and we don't pay much
attention to them, causing that the pipelines are always red, increasing
the work required to check if there are important failures or not.
Make check-tree optional for branches other than main. This way,
failures will be shown as a "warning", and if a pipeline only shows a
warning we don't need to inspect it.
Previously, the coverity scheduled job seemed to fail
randomly because the image that it expected to use was
not available, due to not depending on the "prep" job.
This commit resolves the problem by making sure
the image is always built when coverity runs.
The current approach is flawed. During a commit of the L3
configuration we do a RTM_GETROUTE to find the next-hop to the DNS
server on the current interface, in order to create the DNS route to
inject into the l3cd. However, we haven't added routes to kernel yet
and so the result of the RTM_GETROUTE is going to be wrong.
In some cases, for example when IPv4 DAD is enabled, the bug can't be
easily noticed because we perform multiple commits for the interface,
and the regular routes are already set in kernel from the 2nd commit
on.
To fix the problem, do the following: during a commit we first add
addresses and routes to platform. Then, we create a list of DNS routes
to configure, we collect the old DNS routes, and do a comparison. If
they changed, we need to add the DNS routes to platform in a 2nd step.
Note that in the previous approach we tracked the routes in the
committed-l3cd object of the l3cfg, and so they were applied to kernel
automatically. Because of the 2-step requirement, that no longer works
and we must apply the DNS routes manually.
Fixes: 5449b18a94 ('core: support automatically adding DNS routes')
Don't try to add the routing rule that points to the table containing
DNS routes at every commit.
Instead, look into the platform cache to see if the rule already
exists and add it only when needed.
Using `n_dhcp4_c_connection_start_request()` will cause staying in
`connection->request`, as a result, it will cause the resending of
DHCPRELEASE and DHCPDECLINE message, thus, use
`n_dhcp4_c_connection_send_request()` directly instead to avoid
unnecessary retransmission timeout, as suggested by
f030927a54 (r1531834009).
We should not send the DHCP release message when udp socket is still in
the PACKET state, this state is typically used during the discovery and
offer phases, where the client broadcasts DHCP packets like DHCPDISCOVER
and receives responses like DHCPOFFER. At this point, the client has no
lease because it has not yet completed the DHCP handshake.
In the scenario for sending the release message, we need to guarantee
that NM only sends the release message when the client received a lease
from the server. However, there is some distinction between the
`l3cd_curr` and `l3cd_next` when ACD is pending, because `l3cd_curr` is
NULL but `l3cd_next` is not NULL when ACD is pending. Regardless of
whether ACD is pending or completed, these are all considered the client
have received the release from the server. Therefore, adapt the function
`nm_dhcp_client_get_lease()` to control whether to get next or current
lease.
Now "fedpkg prep" command is generating a directory with the "-build"
suffix containing the build directory inside. We need to extract it.
Real example:
If the script is used for a branch related to nm-1-46, the "fedpkg prep"
command will generate a NetworkManager-1.46-build/ directory containing
the NetworkManager-1.46/ sources directory. We just need to move the
NetworkManager-1.46/ out.
In the "Action()" D-Bus method, the "nameservers" key used to contain
an array of binary addresses. If we change the key to contain
something else, there can be problems when the NM and the
NM-dispatcher versions mismatch (right after an upgrade or a
downgrade).
To avoid such problem, still send the old key in the old format, and
introduce a new key for the new format. The new format carries the
name servers as a string list, and can encode encrypted DNS servers.
Introduce a new kernel command line option named "rd.net.dns" that can
be used to specify a global name server. It accepts name server in a
URI-like form, as for example:
rd.net.dns=dns+tls://[fd01::1]:5353#mydomain.com
Accept name servers specified with an URI syntax in the global
configuration. A plugin that doesn't support a specific scheme can
decide to ignore it and use only the servers it understands. At the
moment there is no plugin that supports DNS-over-TLS servers in the
global configuration.
Introduce new functions to parse and normalize name servers. Their
name contains "dns_uri" because they also support a URI-like syntax
as: "dns+tls://192.0.2.0:553#example.org".
Remove unused "server_name" argument. It is still possible to pass the
server name, if needed, with the nm_l3_config_data_add_nameserver()
function. After this change, rename the function to
nm_l3_config_data_add_nameserver_addr(), since the function only
accepts an address.
We only add to Tier 3 distro versions that ship a version of NM equal or
older to the one that we are testing. As CentOS Stream uses "main", no
stable version will be tested on it.
Force to test CentOS Stream as Tier 3.
