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.
Watch for NMSettingConnection changes and creation signals and convert
them to IWD format and write them to the configured IWD profile storage
directory. The logic is off by default and gets enabled when the new
iwd-config-path setting in nm.conf's [main] group is set to a path to
an existing directory.
The idea here is that when a user edits an NM connection profile, the
change is immediately mirrored in IWD since IWD watches its
configuration directory using inotify. This way NM clients can be used
to edit 802.1x settings, the PSK passphrase or the SSID -- changes that
would previously not take effect with the IWD backend.
Some precautions are taken to not make connections owned by a user
available to other users, such connections are not converted at all.
In all other cases where a connection cannot be converted sufficiently
well to the IWD format, for various reasons, we also give up and not
mirror these connections.
Due to IWD limitations and design differences with NM this logic has
many problems where it may not do its task properly. It's meant to work
on a best-effort and "better than nothing" basis, but it should be safe
in that it shouldn't delete users data or reveal secrets, etc. The most
obvious limitation is that there can be multiple NM connections
referring to the same SSID+Security tuple and only one IWD profile can
exist because the filename is based on only the SSID+Security type. We
already had one NM connection selected for each IWD KnownNetwork and
referenced by a pointer, so we ignore changes in NM connections other
than that selected one.
Add code that can take an NMConnection and convert it to the IWD
network config file format so as to be able to mirror NM connection
profiles to IWD connection profiles and make basic editing IWD
profile possible from nm-connection-editor. The focus here is on 802.1x
settings.
When using IWD-side autoconnect mode (current default), in .deactivate()
and .deactivate_async() refrain from commanding IWD to actually
disconnect until the device is managed. Likely the device is already
disconnected but in any case it's up to IWD to decide in this mode.
Calling IWD device's .Disconnect() D-Bus method has the side effect of
disabling autoconnect and doing this while NM is still in platform-init
was unexpectedly leaving the device without autoconnect after
platform-init was done, according to user reports.
Fixes: dc0e31fb70 ('iwd: Add the wifi.iwd.autoconnect setting')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/786
nm_utils_ptrarray_find_binary_search() had two additional output
arguments: the first and last index -- in case the sorted list contains
duplicates.
That's nice, and was used in the past. But now, those output arguments
are no longer used.
So drop them from nm_utils_ptrarray_find_binary_search().
Actually, we could now also drop the previous variant
nm_utils_ptrarray_find_binary_search_range(), as it's only used by unit
tests. However, although not rocket science, getting this right is not
entirely trivial, so lets keep the code in case we need it again.
Asserting against user input is not nice, because it always requires the
caller to check the value first. Don't do that.
Also, don't even check. You can set NM_SETTING_WIRED_S390_OPTIONS
property to any values (except duplicated keys). The C add function
should not be more limited than that. This is also right because
we have verify() which checks for valid settings. And it does so beyond
only checking the keys.
So you could set NM_SETTING_WIRED_S390_OPTIONS properties to invalid
keys. And you could use nm_setting_wired_add_s390_option() to set
invalid values. No need to let nm_setting_wired_add_s390_option() check
for valid keys.
Note that we take defines from "src/core/nm-config.h" which
are GPL-2.0-or-later licensed.
libnm-base we want to include in other LGPL licensed sources,
we it must also be LGPL.
"relicense" the code that I take. I don't think it's a problem, because:
- these are only plain defines. To which extend is that even
copyrightable?
- as far as I see, all the code was contributed by people who agreed
to such relicensing. See RELICENSE.md file.
src/core/initrd/tests/test-cmdline-reader.c: In function test_if_off:
src/core/initrd/tests/test-cmdline-reader.c:564:5: error: for loop initial declarations are only allowed in C99 mode
for (int i = 0; i < G_N_ELEMENTS(conn_expected); ++i) {
^
src/core/initrd/tests/test-cmdline-reader.c:564:5: note: use option -std=c99 or -std=gnu99 to compile your code
If the modem is connected, and registrations drops, and then is restored, the
connection isn't re-activated.
The fix was simply to change modem_state_cb to not return after setting the
state to failed, which allows nm_device_queue_recheck_available to be called,
which queues a state transition to UNAVAILABLE.
This patch fixes two issues,
- If ofono returns InProgress, don't treat as a PREPARE_FAILURE.
- If context in question is already active, instead of trying to wait
for "Active" property to change, check the current state of context
properties, and if it is Active = true, fetch the rest of context
settings and process them
Original bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1565717
Co-Authored-by: Bhushan Shah <bshah@kde.org> [rebase patch to upstream,
and adjust it to newer coding style]
If an existing connection has an interface name set and the generator
finds a BOOTIF argument, it creates a new connection for BOOTIF.
Instead, the generator should set the MAC in the existing connection;
this sounds more correct and it is what the network-legacy module
does.
https://bugzilla.redhat.com/show_bug.cgi?id=1915493
802-1x.optional=yes means that NM should tolerate a failure or a
timeout of the 802.1X authentication and should keep the connection
up. Even if the authentication doesn't succeed, NM keeps the
supplicant running so that it can continue trying.
If the supplicant disappears because it crashed or was killed
externally, NM should fail the connection so that it can be retried.
The current code is wrong also because after releasing the supplicant
interface, it calls wired_auth_cond_fail() which tries to connect a
signal to priv->supplicant.iface (which is NULL).
https://bugzilla.redhat.com/show_bug.cgi?id=1934291https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/776
Currently we unconditionally reset the MAC to the previous value after
releasing ports. This has some disadvantages:
- by default, after the last port is removed the bond will have one
of the previous port's address, which could conflict with the port;
- in some cases, changing the bond MAC is not possible. For example
when the bond is active-backup and has fail_over_mac=1|2. In such
case the netlink call succeeds, but the address doesn't
change; then NM would keep waiting for some time.
Don't try to restore the MAC unless the bond connection has a cloned
MAC set.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/775
