If IPv6 is disabled, changing the IPv6 MTU fails and NM complains with
a warning. Since this error is expected and doesn't do any harm,
downgrade the logging level to DEBUG.
Since IPv6 kernel support can be built as a module, we have to check
the existence of /proc/sys/net/ipv6 every time. Instead of checking it
and then setting the MTU (adding one /proc access for everyone), just try
to set the MTU; in case of failure, determine the reason for the error.
https://bugzilla.redhat.com/show_bug.cgi?id=1840989https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/585
Currently NMIP4Config and NMIP6Config both track the data to be
configured, they expose properties on D-Bus, and they have logic for
capturing and applying settings to platform.
We will split that.
- NMIP4Config and NMIP6Config will expose data on D-Bus.
- NML3Cfg will have the logic for handling IP configuration.
- NML3ConfigData will track data to be configured.
NML3ConfigData mirrors NMIP4Config/NMIP6Config in many aspects. For now,
this duplicates a lot of code. More will be done later. Eventually,
NMIP4Config/NMIP6Config will drop the duplicated functionality.
The NML3Cfg instance tracks and prepares the IP configuration.
However, that is also partly exposed on other objects, like
NMIP4Config's "route-data" property.
Add an API, so that NMIP4Config can register itself to be notified
when something relevant changes.
This is an alternative to standard GObject properties and signals. They
often seem more effort than worth. That is, because in this case,
NMIP4Config.route-data has no other task then to re-emit the signal.
So, to implement that with GObject properties/signals, we would have to
add a property/signal to NML3Cfg, subscribe to it from NMIP4Config,
and remit the signal. An alternative is to bind properties, but that
would still be quite some extra code, and unclear that it would be
simpler. Not to mention the overhead, as bindings are themself full
GObject instances, that register to and emit signals by name.
We have several fields in the header file, so that the frequently used accessors
can be inlined. However, we also want some private data. Add a structure for that.
We need to react to platform changes. Also, we usually want to delay the
reaction to an idle handler.
Instead of subscribing each NML3Cfg instance itself to platform changes,
let only NMNetns do that. The goal is of course that each platform event
only needs to notify the NML3Cfg instance, which collects the events and
schedules them on the idle handler.
_ip_iface_update() only had one caller. The code is simpler to
understand by inlining it.
Also, it is relevant where and how we set ip_iface_ and ip_ifindex_
fields. Keep the places few and easily understandable.
and rename to nm_utils_ip_route_attribute_to_platform(). The function is independent
from NMIP4Config. We also will use it outside of NMIP4Config. Also, "NetworkManagerUtils.c"
already has similar functions that parse libnm structures to internal structures.
_nm_ip_config_best_default_route_set() doesn't really do anything
special. Use the generic helper function for the same job.
Also because NMIP4Config in the current form will be replaced by
something else, and this code needs to change.
Currently, we would not mark non-unicast routes with their type, so they
would wrongly appear as unicast routes in the D-Bus API.
That is wrong. For now, just hide them.
Fixes: 5d0d13f570 ('platform: add support for local routes')
A connection that fails due to dependency-failed is not able to
reconnect until the master connection activates again; when this
happens, the master clears the blocked reason for all its slaves in
activate_slave_connections() and tries to reconnect them. For this to
work, the slave should be marked as blocked when it fails with
dependency-failed.
If the device state change (to disconnected or unmanaged) triggered by
a sleep event happens after the wake, the devices becomes wrongly
unmanaged and it's necessary to manually manage it again, or restart
NM.
During the wake event we should disconnect the device_sleep_cb()
callback for all devices because we don't want to react to state
changes anymore; in particular we don't need to detect when the device
becomes disconnected to unmanage it.
"nm-device.c" is large and complicated. It's hard to find relevant places
that modify the ifindex,ip_ifindex,iface,ip_iface fields.
Mark them as const, to make that easier.
When NM fails to connect to teamd during an activation, it sets the
device state to FAILED. Eventually the device will become DISCONNECTED
and will call the ->deactivate() method that will perform the cleanup
of timers, teamd process and teamdctl instance.
However, in this way, when the device is DISCONNECTED timers are still
armed and can be triggered in the wrong state. Instead, perform the
cleanup immediately on failure.
https://bugzilla.redhat.com/show_bug.cgi?id=1856723
When using VRF devices we must pre-generate dependent local
routes in the VRF's table otherwise they will be incorrectly added
to the local table instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1857133
Fixes: a199cd2a7d ('core: add dependent local routes configured by kernel')
Kernel will reject setting "active_slave", if the interface is not enslaved or not
up. We already handle that by setting the option whenever we enslave an interface.
However, we also must not set it initially, otherwise we get an ugly error log message:
NetworkManager[939]: <debug> [1594709143.7459] platform-linux: sysctl: setting net:/sys/class/net/bond99/bonding/active_slave to eth1 (current value is )
NetworkManager[939]: <error> [1594709143.7459] platform-linux: sysctl: failed to set bonding/active_slave to eth1: (22) Invalid argument
NetworkManager[939]: <warn> [1594709143.7460] device (bond99): failed to set bonding attribute active_slave to eth1
...
kernel: bond99: (slave eth1): Device is not bonding slave
kernel: bond99: option active_slave: invalid value (eth1)
See-also: https://bugzilla.redhat.com/show_bug.cgi?id=1856640https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/577
- the arp_ip_target option in the settings might not have normalized
IP addresses or duplicates. If there would be duplicates, setting
them twice would fail with EINVAL. Hence, first normalize them
and make them unique.
- if what we want to set is identical to what is already set, don't
do anything.
When dispose() is called, there can't be any pending operation because
they keep a reference to the device. Instead, there can be a a queued
operation not yet executed. Destroy it.
When a 'ip=auto6' option is passed to kernel, the old dracut network
module only sets accept_ra in kernel and wait for the address to
appear. Instead, with a 'ip=dhcp6' option it starts 'dhclient -6',
leaving accept_ra to the initial value (that is already 1). So
'ip=dhcp6' in practice does kernel IPv6 autoconf and DHCPv6 at the
same time, without honoring the 'Managed' flag of the router
advertisement.
It seems that the only reason to have distinct 'auto6' and 'dhcp6'
options was that network module did not support starting DHCPv6 only
when necessary based on the M flag of the RA; so the user had to
specify if DHCPv6 was needed or not.
Given that 1) NM is smarter and can start DHCPv6 only when needed by
RA; 2) DHCPv6 alone only gets a /128 address without a prefix route
and so it's not useful; then it makes sense to generate a connection
with 'ipv6.method=auto' for both 'ip=auto6' and 'ip=dhcp6'.
https://bugzilla.redhat.com/show_bug.cgi?id=1854323https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/571
They serve a similar purpose.
Previously, nm-json-aux.h contained the virtual function table for accessing
the dynamically loaded libjansson. But there is no reason why our own
helper functions from nm-json.h cannot be there too.
We anyway load libjansson with dlopen(), and already before it could
happen that libjansson is not available. In that case, we would not
crash, but simply proceed without json validation.
Since libnm-core no longer uses libjansson directly, but only via
"nm-glib-aux/nm-json.h", we can just always compile with that, and use
it at runtime. That means, libjansson is not a build dependency for
libnm anymore, so we don't need a compile time check.
Note that if you build without libjansson, then JANSSON_SONAME is
undefined, and loading it will still fail at runtime. So, even if
we now always build with all our code enabled, it only works if you
actually build with libjansson. Still, it's simpler to drop the
conditional build, as the only benefit is a (minimally) smaller
build.
Pre-generate routes in the local table that are configured
by kernel when an ip-address is assigned to an interface.
This helps NM taking into account routes that are not to be deleted
when a connection is reapplied (or deactivated) on an interface instead of only
ignoring (when pruning) IPv6 routes having metric 0 and routes belonging
to the local table having 'kernel' as proto.
https://bugzilla.redhat.com/show_bug.cgi?id=1821787
@routes are the list of routes we want to configure. This contains
routes from DHCP and manual routes in the profile. It also contains
externally present routes, including the metric=0 routes in the local
table.
Trying to add an IPv6 route with metric zero adds instead a route with
metric 1024.
Usually, we wouldn't do that, because that route was present externally,
so it possibly is still present (in the platform cache) during sync and
we skip the addition. However, there is a race where the external route
might just disappear and we'd add a route with metric 1024.
Avoid that.
NM will now sync all tables when a connection has specified
at least 1 local route in 'ipv[4|6].routes' to correctly
reconcile local routes when reapplying connections on a device.
If the connection has no local routes only the main table will be
taken into account preserving the previous NM's behaviour.
https://bugzilla.redhat.com/show_bug.cgi?id=1821787
Pre-generate the device multicast route in the local table that are configured
by kernel when an ipv6-address is assigned to an interface.
This helps NM taking into account routes that are not to be deleted
when a connection is reapplied on an interface.
https://bugzilla.redhat.com/show_bug.cgi?id=1821787
NetworkManager can't control the name of the PPP interface name
created by pppd; so it has to wait for the interface to appear and
then rename it. This happens in nm_device_take_over_link() called by
nm-device-ppp.c:ppp_ifindex_set() when pppd tells NM the ifindex of
the interface that was created.
However, sometimes the initial interface name is already correct, for
example when the connection.interface-name is ppp0 and this is the
first PPP interface created.
When this happens, nm_device_update_from_platform_link() is called on
the NMDevicePPP and it sets the device ifindex. Later, when pppd
notifies NM, nm_device_take_over_link() fails because the ifindex is
already set:
nm_device_take_over_link: assertion 'priv->ifindex <= 0' failed
Make nm_device_take_over_link() more robust to cope with this
situation.
https://bugzilla.redhat.com/show_bug.cgi?id=1849386
Support the creation of parameterless 'prio' qdiscs. The kernel needs
a TCA_OPTIONS attribute initialized with default values. We currently
don't support modifying the qdisc parameters.
