audit_encode_nv_string() is documented that it might fail. Handle
the error.
Also, the returned string was allocated with malloc(). We must free
that with free()/nm_auto_free, not g_free()/gs_free.
Try to workaround a coverity warning:
30. NetworkManager-1.39.3/src/core/vpn/nm-vpn-connection.c:2000:
overrun-buffer-val: Overrunning array "address.ax.address_ptr" of 1
bytes by passing it to a function which accesses it at byte offset 3.
libnm-client-impl/nm-client.c:8398: warning: multi-line since docs found
libnm-client-impl/nm-device-macvlan.c:115: warning: multi-line since docs found
libnm-client-impl/nm-device-vxlan.c:540: warning: multi-line since docs found
libnm-client-impl/nm-device-vxlan.c:92: warning: multi-line since docs found
libnm-core-impl/nm-setting-ethtool.c:41: warning: multi-line since docs found
libnm-core-impl/nm-setting-ip-config.c:2475: warning: multi-line since docs found
libnm-core-impl/nm-setting-ip-config.c:2504: warning: multi-line since docs found
The typedefs in nm-types.h confuse gtkdoc-scan. It generates a
libnm-sections.txt file like this:
<SECTION>
<FILE>nm-types</FILE>
<TITLE>NMDeviceOvs</TITLE>
NMAccessPoint
NMActiveConnection
NMCheckpoint
NMClient
NMDevice
...
Note the wrongly picked title and, more importantly, the object types in
a bogus section. This in turn makes gtkdoc-mkdb fail to include the
property and signal documentation in appropriate sections.
Without nm-types.h, we need to mind the header dependencies. This means
that we need to order the headers that define types before the ones that
use them. Also, we need to break the depencency loops in few palces.
e4af93228e37 probe: forget lease after a NAK
c39e1fe74463 connection: discard NAKs from other servers in SELECTING
git-subtree-dir: src/n-dhcp4
git-subtree-split: e4af93228e3772bbb443ec1237252e6a2f3e3dd7
If we have a lease and we get a NAK renewing/rebinding it, the lease
is lost.
Without this, probe->current_lease remains set and after the next
DISCOVER/OFFER round, any call to n_dhcp4_client_lease_select() will
fail at:
if (lease->probe->current_lease)
return -ENOTRECOVERABLE;
As in:
[5325.1313] dhcp4 (veth0): send REQUEST of 172.25.1.200 to 255.255.255.255
[5325.1434] dhcp4 (veth0): received NACK from 172.25.1.1
[5325.1435] dhcp4 (veth0): client event 3 (RETRACTED)
[5325.1436] dhcp4 (veth0): send DISCOVER to 255.255.255.255
[5325.1641] dhcp4 (veth0): received OFFER of 172.25.1.200 from 172.25.1.1
[5325.1641] dhcp4 (veth0): client event (OFFER)
[5325.1641] dhcp4 (veth0): selecting lease failed: -131 (ENOTRECOVERABLE)
Upstream: https://github.com/nettools/n-dhcp4/pull/33
Upstream: e4af93228ehttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/993e43b1791a3 ('Merge commit 'e23b3c9c3ac86b065eef002fa5c4321cc4a87df2' as 'shared/n-dhcp4'')
Use a union, it makes more sense.
Note that with union, C's struct initialization might not sufficiently
set all fields to the default. In practice yes, but theoretically in C
a NULL pointer and floats must not have all zero bits, so the following
is not guaranteed to work:
struct {
int some_field;
union {
void *v_ptr;
int v_int;
};
} variable = {
.some_field = 24,
};
assert(variable.union.v_ptr == 0);
assert(variable.union.v_int == 0);
When initializing the variable, we should not rely on automatically
initialize all union members correctly. It cannot at the same time
set NULL pointers and zero integers -- well, on our architectures it
probably can, but not as far as guaranteed by C language.
We need to know which union field we are going to use and initialize
it explicitly.
As we know the provider type, we can do that.
Also, maybe in the future we need special free/unref calls when
destroying the type specific data in NMCSProviderGetConfigIfaceData.
As we know the provider, we can.
Note that having type specific data in NMCSProviderGetConfigIfaceData.priv
is a layering violation. But it is still simpler than implementing
type specific handlers (callbacks) or tracking the data somewhere else.
After all, we know at compile time all the existing provider types.
Let NMCSProviderGetConfigIfaceData.get_config_data have a pointer to the
NMCSProviderGetConfigTaskData. This will allow two things:
- at several places we pass on `nm_utils_user_data_pack(get_config_data,
config_iface_data)` as user data. We can avoid that, by just letting
config_iface_data have a pointer to get_config_data.
- NMCSProviderGetConfigIfaceData contains a provider specific field
"priv". That may also require special initialization or destruction,
depending on the type. We thus need access to the provider type,
which we have via iface_data->get_config_data->self.
Also let NMCSProviderGetConfigTaskData have a pointer "self" to the
NMCSProvider. While there was already the "task", which contains the
provider as source-object, this is more convenient.
The order of IPv4 addresses matters, in particular if they are in
the same subnet. Kernel will mark all but the first one as "secondary".
In NetworkManager's ipv4.addresses, the first address is the primary.
It seems that on aliyun cloud, "private-ipv4s" URL may give the
addresses in arbitrary order. The primary can be fetched from
"primary-ip-address".
Fix that by also fetching "primary-ip-address". Then, resort the array
so that the primary is the first one in the list.
https://bugzilla.redhat.com/show_bug.cgi?id=2079849
For some device types the attach-port operation doesn't complete
immediately. NMDevice needs to wait that the operation completes
before proceeding (for example, before starting stage3 for the port).
Change attach_port() so that it can return TERNARY_DEFAULT to indicate
that the operation will complete asynchronously. Most of devices are
not affected by this and can continue returning TRUE/FALSE as before
without callback.
Try to do one change at a time when reconfiguring addresses, to not
remove several/all addresses at once.
For IP addresses, kernel cares about the order in which they were added.
This mostly affects source address selection, and the "secondary" flag
for IPv4 addresses. The order is thus related to the priority of an
address.
There is no direct kernel API to change the order. Instead, we have to
add them in the correct order. During a sync, if an address already
exists in the wrong order, we need to remove it, and re-add it.
Btw, with IPv4 addresses added first via netlink are the primary
address, while with IPv6 it's reverse.
Previously, we would first iterate over all addresses and remove those
that had a conflicting order. This means, that we would potentially
remove all addresses for a short while, before readding them. That seems
problematic.
Instead, first track all addresses that are in the wrong order. And in
the step when we add/update the address, remove it. We now only remove
and address shortly before re-adding it. This way the time for which the
address on the interface is missing is shorter. More importantly, we will
never remove all addresses at the same time.
DHCP leases for a given interface are already exported on D-Bus
through DHCP4Config and DHCP6Config objects. It is useful to have the
same information also available on the filesystem so that it can be
easily used by scripts.
NM already saves some information about DHCP leases in /var, however
that directory can only be accessed by root, for good reasons.
Append lease options to the existing state file
/run/NetworkManager/devices/$ifindex. Contrary to /var this directory
is not persistent, but it seems more correct to expose the lease only
when it is active and not after it expired or after a reboot.
Since the file is in keyfile format, we add new [dhcp4] and [dhcp6]
sections; however, since some options have the same name for DHCPv4
and DHCPv6, we add a "dhcp4." or "dhcp6." prefix to make the parsing
by scripts (e.g. via "grep") easier.
The option name is the same we use on D-Bus. Since some DHCPv6 options
also have a "dhcp6_" prefix, the key name can contain "dhcp6" twice.
The new sections look like this:
[dhcp4]
dhcp4.broadcast_address=172.25.1.255
dhcp4.dhcp_lease_time=120
dhcp4.dhcp_server_identifier=172.25.1.4
dhcp4.domain_name_servers=172.25.1.4
dhcp4.domain_search=example.com
dhcp4.expiry=1641214444
dhcp4.ip_address=172.25.1.182
dhcp4.next_server=172.25.1.4
dhcp4.routers=172.25.1.4
dhcp4.subnet_mask=255.255.255.0
[dhcp6]
dhcp6.dhcp6_name_servers=fd01::1
dhcp6.dhcp6_ntp_servers=ntp.example.com
dhcp6.ip6_address=fd01::1aa
Instead of logging the event-id, which is composed from options that
are already visible in the log, it's more interesting to log that the
lease was merged.
In glib_dep we specify
"-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40"
which is the dependency we use almost everywhere. With g-ir-scanner
this causes compiler warnings:
[xxx] Generating NM-1.0.gir with a custom command
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c: In function ‘dump_object_type’:
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c:252:13: warning: Not available before 2.70
252 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c: In function ‘dump_fundamental_type’:
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c:370:13: warning: Not available before 2.70
370 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
g-ir-scanner: link: gcc -o /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0 /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -L/src/NetworkManager/build/src/libnm-client-impl -Wl,-rpath,/src/NetworkManager/build/src/libnm-client-impl -lnm -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgmodule-2.0 -ludev -lgirepository-1.0 -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lglib-2.0
Work around that.
Meson's gnome.generate_gir() is not very flexibly in allowing to
pass extra `--cflags-begin {} --cflags-end` parameters.
Hack around by adding a pseudo dependency that resets
these defines.
See-also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/331
See-also: 1234e5583a ('build/autotools: avoid compiler warning generating "NM-1.0.gir"')
In practice there is little difference.
Previously, "strbuf" would own the string until the end of the function,
when the "nm_auto_str_buf" cleanup attribute destroys it. In the
meantime, we would pass it on to _fw_nft_call_sync(), which in fact
won't access the string after returning.
Instead, we can just transfer ownership to the GBytes instance. That seems
more logical and safer than aliasing the buffer owned by NMStrBuf with
a g_bytes_new_static(). That way, we don't add a non-obvious restriction
on the lifetime of the string. The lifetime is now guarded by the GBytes
instance, which, could be referenced and kept alive longer.
There is also no runtime/memory overhead in doing this.
On rhel-8.7, we are going to no longer use the pre-generated docs, but
instead generate them on build time with "gtk-doc-1.28-4.el8".
That version of gtk-doc has problems with these deprecated/available
macros on the structs, so it will generate:
/usr/share/gtk-doc/html/libnm/libnm-nm-vpn-service-plugin.html
/usr/share/gtk-doc/html/libnm/libnm-nm-vpn-plugin-old.html
instead of
/usr/share/gtk-doc/html/libnm/NMVpnServicePlugin.html
/usr/share/gtk-doc/html/libnm/NMVpnPluginOld.html
Newer gtk-doc versions don't have this problem.
But as we usually don't use these macros on typedefs (only on functions), and as
1.2 is very old already, it seems simpler to just drop this (instead of
fixing gtk-doc).
See-also: https://bugzilla.redhat.com/show_bug.cgi?id=1995915
