Clarify that detect() needs to succeed before get_config().
I thought it's sort of common sense, but it's better to be explicit as
we're going to rely on that.
In file included from ./src/libnm-std-aux/nm-default-std.h:102,
from ./src/libnm-glib-aux/nm-default-glib.h:11,
from ./src/libnm-glib-aux/nm-default-glib-i18n-prog.h:13,
from ./src/core/nm-default-daemon.h:11,
from src/core/nm-connectivity.c:8:
src/core/nm-connectivity.c: In function ‘nm_connectivity_check_start’:
./src/libnm-std-aux/nm-std-aux.h:180:12: error: ‘reason’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (expr) \
^
src/core/nm-connectivity.c:1055:29: note: ‘reason’ was declared here
const char *reason;
^~~~~~
The compiler may dislike this:
CC src/core/platform/tests/libNetworkManagerTest_la-test-common.lo
In function '_ip_address_add',
inlined from 'nmtstp_ip4_address_add' at ../src/core/platform/tests/test-common.c:1892:5:
../src/core/platform/tests/test-common.c:1807:63: error: array subscript 'NMIPAddr {aka const struct _NMIPAddr}[0]' is partly outside array bounds of 'in_addr_t[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds]
1807 | peer_address->addr4,
| ~~~~~~~~~~~~^~~~~~~
../src/core/platform/tests/test-common.c: In function 'nmtstp_ip4_address_add':
../src/core/platform/tests/test-common.c:1886:36: note: object 'peer_address' of size 4
1886 | in_addr_t peer_address,
| ~~~~~~~~~~~~^~~~~~~~~~~~
...
Fixes: 06aafabf14 ('platform/test: add test adding IPv4 addresses that only differ by their peer-address')
Now the settings in the [global-dns] section are used *in addition* to
connection-specific ones. Only the global domains sections, when
valid, override connection settings. Update the man page to clarify
that.
Fixes: 1f0d1d78d2 ('dns-manager: always apply options from [global-dns]')
The global configuration now can be valid when there are no global
domains defined. The dnsmasq backend must process it and then, if
there is no global default domain, also process the per-connection
settings.
Fixes: 1f0d1d78d2 ('dns-manager: always apply options from [global-dns]')
The link object is no longer valid after the cache gets updated in
nm_platform_link_change().
Fixes: e02fd76d9f ('platform: support changing link properties')
OVS interfaces are special: the kernel link is created only after the
device is attached to the ovs-port, and as with all ports this happens
during stage3(ip-config). That means that the link doesn't exist
during stage2(config); therefore, explicitly update link properties
once the link appears.
There are many functions to replace properties of a link
(link_set_address, link_set_mtu, link_set_name, link_change,
etc.). Eventually, they will be replaced by a function that does
everything and removes all the code duplication.
That function will be named link_change(); rename the current
link_change() to link_change_extra().
We need to set the ethtool and tc properties for assumed devices,
since they go through a normal activation. External devices should not
be touched by NM.
We are passing to the plugin only 'sett_flags', which is the bitmask
of flags to change and works together with 'sett_mask'; however,
plugins interpret that value as the new flags value. The result is
that if there is no change needed (0/0), the existing flags are lost.
Simple reproducer:
ip link add dummy1 type dummy
ip link set dummy1 up
ip addr add dev dummy1 fd01::12/64
sleep 1
# now, a external connection is created by NM
echo "BEFORE:"
cat /run/NetworkManager/system-connections/dummy1.nmconnection | grep "nm-generated\|volatile\|external"
# just add a new address to the interface to make it lose
# the external flag
ip addr add dev dummy1 172.25.42.1/24
sleep 1
echo "AFTER:"
cat /run/NetworkManager/system-connections/dummy1.nmconnection | grep "nm-generated\|volatile\|external"
Output:
BEFORE:
nm-generated=true
volatile=true
external=true
AFTER:
Fixes: d35d3c468a ('settings: rework tracking settings connections and settings plugins')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1548
Add overrides for properties constants of new objects to allow to match them with their
object type as it was the case for former objects.
Specify the types of properties with element-types.
Namespace Attributes so that they are logically sorted.
Remove several skips to allow to use the entirety of the visible methods.
Allows to use this function in GObject introspected languages.
Also workaround a current issue with the gtk-doc parser not taking nested
element-type into account.
Request the extack_msg for nm_platform_ip_route_add() call. Note that we (currently)
don't do anything with it, however requesting it has no downsides. That is, the
message already is heap allocated in the lower layers, so this only affects whether
it will be returned up to nm_platform_ip_route_sync().
It is not clear how that information is relevant. Since it is also
only logged when building with a non-default configure option, this
doesn't seem useful. Drop it.
- unindent the code by "continue" the loop for the irrelevant case.
- fix indentation of comments.
- avoid unnecessary g_strdup() call if the extack message is NULL.
Consistently name those variables and parameters "extack_msg".
The previous term "errmsg"/"msg" was not used consistently, and it
is also not clear what message this really is. For netlink, it
is well understood what Extended ACK means.
strlcpy()/g_strlcpy() has a well understood behavior. nla_strlcpy()
did not behave like that. Instead, it also used to always wipe the
remainder of the string, similar to what strncpy() would do.
True, if we do
nla_strlcpy(obj->link.name, tb[IFLA_IFNAME], IFNAMSIZ);
then we might want to clear the remainder and don't care about the
overhead of writing up to 14 bytes unnecessarily... However, actually
all callers of nla_strlcpy() either operate on a buffer that is already
pre-inialized with zero, or they really don't care about the
uninitialized memory after the string. So this was nowhere the desired
behavior.
Change nla_strlcpy() to not wipe the remainder of the buffer, so it behaves
mostly like strlcpy()/g_strlcpy() and as one would expect.
Add nla_strlcpy_wipe(), which on top of it also clears the remaining
buffer. In that aspect, it bears some similarities with strncpy(), but it
differs in other regards from strncpy (always NUL terminating and
returning the srclen). Yes, the name nla_strlcpy_wipe() is maybe
unfamiliar to the user, but it really is like nla_strlcpy() with the
addition to clear the buffer. That seems simple enough to understand
based on the name.
Note that all existing callers of nla_strlcpy() do not care about
clearing the memory, and the change in behavior is fine for them.
