Allow IP prefixes of 0 for routing rules, which are used for specifying a
route for all traffic. (e.g. route all traffic by default with separate
rules to exclude specific IP ranges)
#711
When the link goes away the manager keeps software devices alive as
unrealized because there is still a connection for them.
If the device is software and has a NM-generated connection, keeping
the device alive means that also the generated connection stays
alive. The result is that both stick around forever even if there is
no longer a kernel link.
Add a check to avoid this situation.
https://bugzilla.redhat.com/show_bug.cgi?id=1945282
Fixes: cd0cf9229d ('veth: add support to configure veth interfaces')
We need to handle the case that kernel mangles the configured values. We
already do, but there was a left over nm_platform_lnk_bridge_cmp() that
is still wrong.
Related: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/665
Fixes: ce9211500e ('platform/tests: work around rounding errors for bridge values in unit tests')
This ensures that the argument is some pointer to pointer. This gives a
bit of additional compile time safety, but in general, it still casts
any pointer to pointer (because that's what we require, as most arguments
won't be of type NMDBusObject to begin with).
NM should have been creating the IWD network config files with 0600
permission bits from the beginning since they can contain secrets.
g_key_file_save_to_file() uses 0666 which shouldn't be used even for the
temporary file before setting the final permissions.
Also try to preserve the last modification timestamp of the original
file because it is currently used by IWD when ranking networks for
autoconnect and updating it everytime NM rewrites the file could
potentially affect autoconnect priorities.
Extend nm_utils_file_set_contents to be able to optionally set the last
access + last modification times on the file being created, in addition
to the mode.
There was an attempt in the code to allow using existing system-owned
secrets based on whether the connection had ever succeeded before but
this wasn't implemented properly. Now decide whether existing secrets
are allowed and whether to pass the REQUEST_NEW flag to the secrets
request based on the last connection timestamp and on the network
security type (PSK vs. 802.1X) to align the policy with the policy
inside IWD.
Drop a useless nm_connection_clear_secrets call on the applied
connection just before failing the connection attempt and thus
destroying the applied connection.
Avoid saving agent-owned secrets when converting settings connections
to IWD config files and avoid reacting to NMSettingsConnection updates
that don't seem to touch any non-secret or system-owned-secret settings.
Along with NM_SETTINGS_CONNECTION_UPDATE_REASON_RESET_SYSTEM_SECRETS
and NM_SETTINGS_CONNECTION_UPDATE_REASON_RESET_AGENT_SECRETS, which can
be used in the NMSettingConnection's "updated" handlers to track secrets
updates, add NM_SETTINGS_CONNECTION_UPDATE_REASON_UPDATE_NON_SECRET so
that the handlers can tell when something other than secrets has been
updated in the connection.
It can also potentially be used in _connection_changed_update in
src/core/settings/nm-settings.c to stop emitting the
NetworkManager.Settings.Connection.Updated() dbus signal if only secrets
are being updated (on agent queries etc.) if it is deemed to be correct.
NMLldpListener API was a (refcounted) GObject with start/stop methods.
That means, a listener instance itself had state, namely whether it was
running and which ifindex was used. And this was not only internal
state, but the user had to care about this.
That is all entirely unnecessary. Beside requiring more code and having
more overhead (of a GObject), it is also harder to use. NMDevice not
only need to care whether priv->listener is set, it also needs to care
whether it is running.
Simplify this. The NMLldpListener is no longer ref-counted. As such, the
notify callback is set in the constructor, and the user will stop
receiving notifications by destroying the instance. Furthermore, the instance
can only use one ifindex, that is determined at construct time too.
The state that NMLldpListener now represents is simpler. This simplifies
the usage from NMDevice, which now only call lldp_setup() to enable and
disable the listener.
There is also no need to restart the LLDP listener. The only exception
is, if the ifindex changes. In that case, we throw away the old instance
and create a new one. Otherwise, the LLDP listener is itself responsible
to keep running. There is no excuse for it to fail, and if it does, it needs
to autorecover as good as it can.
It's not clear why we would need to restart the instance. It
is supposed to work, and recover automatically.
The only thing that restarting should be necessary, is to change the
ifindex. But this is not the right place for handling changes of ifindex.
For certain options, kernel stores the numeric values in jiffies scale,
while the user space value is in USER_HZ (1/100th of a second) scale.
Jiffies scale depends on HZ setting (CONFIG_HZ), and depending on kernel
configuration its 100, 250, 300, or 1000.
That means, the round trip of clock_t_to_jiffies()/jiffies_to_clock_t()
has different rounding errors, depending on CONFIG_HZ and it maybe be
+/- 1 of the requested value.
Since the rounding error depends on CONFIG_HZ, we cannot find "good"
values for testing, that always behave the same. So we need to
workaround that.
Normalize the bridge values, if they look as if the value was mangled
due to rounding.
Related: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/665
NM_DHCP_STATE_DONE is for when the client reports that it is shutting
down. If we manually stop it, we should set the TERMINATED state, so
that NMDevice doesn't start a grace period waiting for a renewal.
This fixes the:
device (enp1s0): DHCPv4: trying to acquire a new lease within 90 seconds
message printed when NM is shutting down.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/802
build_message() is an internal helper function with a very specific
purpose.
Let's change it to take an NMStrBuf argument for generating
the string. The advantage is that we don't need to allocate and
free the buffers in between, but can just reuse it.
When using a GValue, we really should call g_value_unset(). Otherwise
it is a code smell, even if we technically only created GValue with
static strings and integers.
But changing that is not easy, because the AuditField structs are
allocated on the stack, and in different functions. So we cannot just
pass a GDestroyNotify to GPtrArray to cleanup all those fields, because
by then they will be out of scope.
The proper solution would be to heap allocate the AuditField struct, add
them to the GPtrArray, and free them with the free function. But that
seams really unnecessary overhead, for something that is correct in
practice. Let's accept the fact that by the time the fields array gets
destroyed, it contains dangling pointers.
If we already embrace the dangling pointers and that stuff is allocated
on the stack and that we don't need to free, also get rid of GValue
and use our plain NMValueType and NMValueTypUnion. GValue really doesn't
give us much here. And it only makes us wonder: is it OK to not call
g_value_unset()? With the plain tracking of the values, we know that
it is OK.
The "_lst" suffix already indicates that this is a list. We have
a list of ip-configs, so the prefix should be singular. It also matches
the "NMDnsConfigIPData.ip_config_lst" field.
The main reason for this renaming is that I want to search the file
for /ip_config_lst/ and find both the list head and the list elements.
Review and replace usages of the two nm_connection_to_dbus() flags
marked deprecated in commit 84648e562c98 ('libnm: Refactor
NM_CONNECTION_SERIALIZE_* flags'):
NM_CONNECTION_SERIALIZE_NO_SECRETS and
NM_CONNECTION_SERIALIZE_ONLY_SECRETS.
Use the new nm_connection_to_dbus() flags to filter secrets instead of
cloning connections and using
_nm_connection_clear_secrets_by_secret_flags() and then serializing all
secrets in NMSettingsConnection. Fix a related comment.
initscripts don't support "$VLAN_ID". They actually support "$VID",
which NetworkManager doesn't.
"$VLAN_ID" was introduced by commit 10b32be37b ('ifcfg-rh: various VLAN
cleanups'). It has a comment about "backward compatibility" for the case
where the reader would ignore "$VLAN_ID" if "$DEVICE"'s name contains
a suffix that is parsable as VLAN ID.
That is wrong. If a new feature gets introduce (like NetworkManager
supporting "$VLAN_ID"), then there is no way that an older version of the
tool -- which doesn't know the new feature yet (initscripts) -- supports it.
This is not what backward compatibility means. Backward compatibility
means that if a user has an old ifcfg-file without "$VLAN_ID", then we
continue parsing it as before.
Consider, when a user (or NetworkManager) writes a configuration
DEVICE=vlan9
PHYSDEV=eth0
VLAN_ID=10
then it makes no sense to ignore VLAN_ID=10 and use "9" instead.
Otherwise the user (or NetworkManager) should not have written the
file this way.
Also, NetworkManager profiles support "connection.interface-name=vlan9"
together with "vlan.id=10". Such a configuration is valid and must be
expressible in ifcfg-rh format. The ifcfg-rh writer code did not somehow
restrict the setting of "$VLAN_ID" to account for this odd behavior. Whenever
NetworkManager in the past wrote VLAN_ID variable to file, it really meant
it.
https://bugzilla.redhat.com/show_bug.cgi?id=1907960https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/794
It's not entirely clear how to treat %NULL.
Clearly "match.interface-name=eth0" should not
match with an interface %NULL. But what about
"match.interface-name=!eth0"? It's now implemented
that negative matches still succeed against %NULL.
What about "match.interface-name=*"? That probably
should also match with %NULL. So we treat %NULL really
like "".
Against commit 11cd443448 ('iwd: Don't call IWD methods when device
unmanaged'), we got this backtrace:
#0 0x00007f1c164069f1 in __strnlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62
#1 0x00007f1c1637ac9e in __fnmatch (pattern=<optimized out>, string=<optimized out>, string@entry=0x0, flags=flags@entry=0) at fnmatch.c:379
p = 0x0
res = <optimized out>
orig_pattern = <optimized out>
n = <optimized out>
wpattern = 0x7fff8d860730 L"pci-0000:03:00.0"
ps = {__count = 0, __value = {__wch = 0, __wchb = "\000\000\000"}}
wpattern_malloc = 0x0
wstring_malloc = 0x0
wstring = <optimized out>
alloca_used = 80
__PRETTY_FUNCTION__ = "__fnmatch"
#2 0x0000564484a978bf in nm_wildcard_match_check (str=0x0, patterns=<optimized out>, num_patterns=<optimized out>) at src/core/nm-core-utils.c:1959
is_inverted = 0
is_mandatory = 0
match = <optimized out>
p = 0x564486c43fa0 "pci-0000:03:00.0"
has_optional = 0
has_any_optional = 0
i = <optimized out>
#3 0x0000564484bf4797 in check_connection_compatible (self=<optimized out>, connection=<optimized out>, error=0x0) at src/core/devices/nm-device.c:7499
patterns = <optimized out>
device_driver = 0x564486c76bd0 "veth"
num_patterns = 1
priv = 0x564486cbe0b0
__func__ = "check_connection_compatible"
device_iface = <optimized out>
local = 0x564486c99a60
conn_iface = 0x0
klass = <optimized out>
s_match = 0x564486c63df0 [NMSettingMatch]
#4 0x0000564484c38491 in check_connection_compatible (device=0x564486cbe590 [NMDeviceVeth], connection=0x564486c6b160, error=0x0) at src/core/devices/nm-device-ethernet.c:348
self = 0x564486cbe590 [NMDeviceVeth]
s_wired = <optimized out>
Fixes: 3ced486f41 ('libnm/match: extend syntax for match patterns with '|', '&', '!' and '\\'')
https://bugzilla.redhat.com/show_bug.cgi?id=1942741
Let's shortcut the test by consistently checking whether num_patterns
is positive before matching.
It's more about having a consistent form of the "if" checks, than
anything else.
When adding an IPv4 address, kernel automatically adds a local route.
This is done by fib_add_ifaddr(). Note that if the address is
IFA_F_SECONDARY, then the "src" is the primary address. That means, with
nmcli connection add con-name t type ethernet ifname t autoconnect no \
ipv4.method manual ipv6.method disabled \
ipv4.addresses '192.168.77.10/24, 192.168.77.11/24'
we get two routes:
"local 192.168.77.10 dev t table local proto kernel scope host src 192.168.77.10"
"local 192.168.77.11 dev t table local proto kernel scope host src 192.168.77.10"
Our code would only generate instead:
"local 192.168.77.10 dev t table local proto kernel scope host src 192.168.77.10"
"local 192.168.77.11 dev t table local proto kernel scope host src 192.168.77.11"
Afterwards, this artificial route will be leaked:
#!/bin/bash
set -vx
nmcli connection delete t || :
ip link delete t || :
ip link add name t type veth peer t-veth
nmcli connection add con-name t type ethernet ifname t autoconnect no ipv4.method manual ipv4.addresses '192.168.77.10/24, 192.168.77.11/24' ipv6.method disabled
nmcli connection up t
ip route show table all dev t | grep --color '^\|192.168.77.11'
sleep 1
nmcli device modify t -ipv4.addresses 192.168.77.11/24
ip route show table all dev t | grep --color '^\|192.168.77.11'
ip route show table all dev t | grep -q 192.168.77.11 && echo "the local route 192.168.77.11 is still there, because NM adds a local route with wrong pref-src"
It will also be leaked because in the example above ipv4.route-table is
unset, so we are not in full route sync mode and the local table is not
synced.
This was introduced by commit 3e5fc04df3 ('core: add dependent local
routes configured by kernel'), but it's unclear to me why we really need
this. Drop it again and effectively revert commit 3e5fc04df3 ('core:
add dependent local routes configured by kernel').
I think this "solution" is still bad. We need to improve our route sync
approach with L3Cfg rework. For now, it's probably good enough.
https://bugzilla.redhat.com/show_bug.cgi?id=1907661
This effectively reverts commit cd89026c5f ('core: add dependent
multicast route configured by kernel for IPv6').
It's not clear to me why this was done or why it would be correct.
True, kernel automatically adds multicast route like
multicast ff00::/8 dev $IFACE table local proto kernel metric 256 pref medium
But NetworkManager ignores all multicast routes for now. So the dependent
routes cannot contain multicast routes as they are not handled. Also,
the code added a unicast route, so I don't understand why the comment
is talking about multicast.
This seems just wrong. Drop it.
