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.
We do the same with autotools.
Well, almost the same. Of course, meson's define_variable only
accepts a list of two strings, to define one variable. So we cannot
also redefine "prefix", unlike configure.ac.
- also accept empty value to autodetect. This makes it similar
to what is done with meson.
- log the chosen udev-dir.
- use ${prefix} instead of $(prefix). It's usually used at other
places.
When building with `mesond -Dprefix=/tmp/nm`, then we would expect
that udev files are installed there (wouldn't we?).
The user can already explicitly set "-Dudev_dir=", or even disable
installing the files with "-Dudev_dir=no".
Note that meson be default pre-populates `get_option("prefix")`, so there
is always something set. So we cannot just act on whether the user set a
prefix. It seems to default to /usr/local.
Note that package builds from Fedora spec file pass "-Dprefix=/usr".
I think we should honor the prefix. However, then it seems wrong to also
honor pkg-config at the same time.
In particular, because `pkg-config --variable=udevdir udev` gives /usr/lib/udev.
That means, if we would just prepend the default prefix "/usr" or "/usr/local"
to "/usr/lib/udev" we get the wrong result.
Note that we already to the same for autotools.
Currently nm_setting_bond_get_option_normalized() and
nm_setting_bond_get_option_or_default() are identical functions. As the
first one is exposed as public API and has a better name, let's drop the
second one.
tun/tap connections can be created using a command such as:
$ nmcli connection add type tun ifname tun0 mode tap owner 1000
They appear in nmcli connection as TYPE "tun".
This patch adds the ability to activate and deactivate this type of
connection using nmtui.
Each connection of TYPE "tun" appears as:
TUN/TAP (<ifname>)
* <connection-name>
Example:
TUN/TAP (tap0)
* bridge-slave-tap0
TUN/TAP (tap1)
bridge-slave-tap1
IPv6 temporary addresses are configured by kernel, with the
"ipv6.ip6-privacy" setting ("use_tempaddr" sysctl) and the
IFA_F_MANAGETEMPADDR flag.
As such, the idea was that during reapply we would not remove them.
However, that is wrong.
The only case when we want to keep those addresses, is if during reapply
we are going to configure the same primary address (with mngtmpaddr
flag) again. Otherwise, theses addresses must always go away.
This is quite serious. This not only affects Reapply. Also during disconnect
we clear IP configuration via l3cfg.
Have an ethernet profile active with "ipv6.ip6-privacy". Unplug
the cable, the device disconnects but the temporary IPv6 address is not
cleared. As such, nm_device_generate_connection() will now generate
an external profile (with "ipv6.method=disabled" and no manual IP addresses).
The result is, that the device cannot properly autoconnect again,
once you replug the cable.
This is serious for disconnect. But I could not actually reproduce the
problem using reapply. That is, because during reapply we usually
toggle ipv6_disable sysctl, which drops all IPv6 addresses. I still
went through the effort of trying to preserve addresses that we still
want to have, because I am not sure whether there are cases where we
don't toggle ipv6_disable. Also, doing ipv6_disable during reapply is
bad anyway, and we might want to avoid that in the future.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
All our sources should include one of the "nm-default*.h" headers
first. That one drags in <config.h>, which must be included first
and a few other basics.
Which is the right "nm-default*.h" header depends on the component. In
case of "nm-daemon-helper.c", it's "libnm-std-aux/nm-default-std.h".
NM_STR_BUF_INIT() and nm_str_buf_init() were pretty much redundant. Drop one of
them.
Usually our pattern is that we don't have functions that return structs.
But NM_STR_BUF_INIT() returns a struct, because it's convenient to use
with
nm_auto_str_buf NMStrBuf strbuf = NM_STR_BUF_INIT(...);
So use that variant instead.
Allow to initialize NMStrBuf with an externally allocated array.
Usually a stack buffer. If the NMStrBuf grows beyond the size of
that initial buffer, then it would switch using malloc.
The idea is to support the common case where the result is small enough
to fit on the stack.
I always wanted to do such optimization because the main purpose of
NMStrBuf is to put it on the stack and ad-hoc construct a string.
I just figured, it would complicate the implementation and add
a runtime overhead. But turns out, it doesn't really.
The biggest question is how NMStrBuf should behave with a pre-allocated
buffer? Turns out, most choices can be made in a rather obvious way.
The only non-obvious thing is that nm_str_buf_finalize() would malloc()
a buffer, but that too seems consistent and what a user would probably
expect. As such, this doesn't seem to add unexpected semantics to the API.
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