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
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.
We just lookup the link info by ifindex. There is no guarantee that that
ifindex is of the expected type, to have a suitable ext-data. Check for
that.
Fixes: a7d2cad67e ('platform/linux: add support for WPAN links')
Autoconnect retries are not being tracked by connection anymore. Now it
is tracked per Device x Connection. In addition, autoconnect might be
blocked for the connection due to no secrets or user requested.
All the properties tracking the retries and blocked time were move to
DevConData and the functions to manipulate them aswell. In NMPolicy the
logic didn't change very much. Instead of looking into the connection
when the device failed activation it looks for DevConData.
This affects the order in which properties are listed in `nmcli
connection show`. The replace-local-rule property should be after the
routing-rule property.
The symbol "nm_active_connection_get_controller" was backported to
1.42.1+. Since 1.44 is not yet released, move the symbol from
libnm_1_44 to libnm_1_42_2, like it is on 1.42.2 release. That way, we
don't need to duplicate the symbol while 1.44 being forward compatible
with 1.42.2.
NM 1.44 is not released yet and 1.42.2 will happen before 1.44.0, so we
can introduce the new API with version libnm_1_42_2 in both releases
without having duplicate symbols on 1.44.
This setting allows the user to remove the local route rule that is
autogenerated for both IPv4 and IPv6. By default, NetworkManager won't
touch the local route rule.
A tentative IPv6 address can still fail DAD, so don't use it to
resolve the hostname via DNS. Furthermore, tentative addresses can't
be used to contact the nameserver and so the resolution will fail if
there is no other valid IPv6 address. Wait that the address becomes
non-tentative.
Currently the only way to return an error code from the daemon helper
is via the process exit code, but that is not enough to fully describe
an error from getaddrinfo(); in fact, the function returns a EAI_*
error code and when the value is EAI_SYSTEM, the error code is
returned in errno.
At the moment, any messages printed to stderr by the helper goes to NM
stderr; instead, we want to capture it and pass it through the logging
mechanism of NM, so that it can be filtered according to level and
domain.
Improve logging:
- log only when something changes
- print the new resolver state, instead of the old one
- rename state "in-progress" to "started"
- log when the resolver state is reset due to DNS changes
