Otherwise, we will try to install "src/nm-dispatcher/nm-dispatcher.conf"
to "/usr/share/dbus-1/system.d", which is not correct, when we want a separate
prefix.
A virtual infiniband profile (with p-key>=0) can also contain a
"connection.interface-name". But it is required to match the
f"{parent}.{p-key}" format.
However, such a profile can also set "mac_address" instead of "parent".
In that case, the validation code was crashing.
nmcli connection add type infiniband \
infiniband.p-key 6 \
infiniband.mac-address 52:54:00:86:f4:eb:aa:aa:aa:aa:52:54:00:86:f4:eb:aa:aa:aa:aa \
connection.interface-name aaaa
The crash was introduced by commit 99d898cf1f ('libnm: rework caching
of virtual-iface-name for infiniband setting'). Previously, it would not
have crashed, because we just called
g_strdup_printf("%s.%04x", priv->parent, priv->p_key)
with a NULL string. It would still not have validated the connection
and passing NULL as string to printf is wrong. But in practice, it
would have worked mostly fine for users.
Fixes: 99d898cf1f ('libnm: rework caching of virtual-iface-name for infiniband setting')
clang 3.4.2-9.el7 does not like this:
$ clang -DHAVE_CONFIG_H -I. -I.. -I../src/libnm-core-public -I./src/libnm-core-public -I../src/libnm-client-public -I./src/libnm-client-public -pthread -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40 -Wall -Werror -Wextra -Wdeclaration-after-statement -Wfloat-equal -Wformat-nonliteral -Wformat-security -Wimplicit-function-declaration -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -Wundef -Wvla -Wno-duplicate-decl-specifier -Wno-format-y2k -Wno-missing-field-initializers -Wno-sign-compare -Wno-tautological-constant-out-of-range-compare -Wno-unknown-pragmas -Wno-unused-parameter -Qunused-arguments -Wunknown-warning-option -Wtypedef-redefinition -Warray-bounds -Wparentheses-equality -Wunused-value -Wimplicit-fallthrough -fno-strict-aliasing -fdata-sections -ffunction-sections -Wl,--gc-sections -g -O2 -MT examples/C/glib/examples_C_glib_add_connection_libnm-add-connection-libnm.o -MD -MP -MF examples/C/glib/.deps/examples_C_glib_add_connection_libnm-add-connection-libnm.Tpo -c -o examples/C/glib/examples_C_glib_add_connection_libnm-add-connection-libnm.o `test -f 'examples/C/glib/add-connection-libnm.c' || echo '../'`examples/C/glib/add-connection-libnm.c
...
../src/libnm-client-public/nm-client.h:149:31: error: redefinition of typedef 'NMClient' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct _NMClient NMClient;
^
Our code base is C11 internally (actually "-std=gnu11"), but this problem
happens when we build the example. The warning is actually correct, because
our public headers should be more liberal (and possibly be C99 or even C89,
this is undefined).
Fixes: 649314ddaa ('libnm: replace nm-types.h by defining the types in respective headers')
We no longer have "nm-types.h", which forward declares most relevant
typedefs. We also don't ensure that each header includes all the
headers that it has a dependency (instead, we rely on the user to
include "NetworkManager.h", which does the right thing).
The "right thing" depends on doing doing it in the right order.
Reorder the includes.
We want to warn the user if they're connecting to an insecure network:
$ nmcli d wifi
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
BA:00:6A:3C:C2:09 Secured Network Infra 2 54 Mbit/s 100 ▂▄▆█ WPA3
FA:7C:46:CC:9F:BE Ye Olde Wlan Infra 1 54 Mbit/s 100 ▂▄▆█ WEP
$ nmcli d wifi connect 'Ye Olde Wlan'
Warning: WEP encryption is known to be insecure.
...
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1224
On Debian 10, `apt-get install meson` gives meson-0.49.2-1.
That version doesn't like certain ternary expressions (while some
that we have are OK), which leads to a crash of meson.
Avoid that.
Fixes: bddffb1731 ('build/meson: honor prefix for udev_dir and don't use pkg-config')
In particular, `dpkg -l` likes to show a pager, when you are on the
terminal. Being on the terminal happens, if you try to reproduce
a test on your own container. So let's avoid that.
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.
