Kernel (sysfs) and iproute2 only use numbers for the multicast_router
option. It's confusing that we name the options differently. Anyway,
that cannot be changed anymore. Clarify the meanings in the
documentation.
https://bugzilla.redhat.com/show_bug.cgi?id=1845608
For simple matches like match.interface-name, match.driver, and
match.path, arguably what we had was fine. There each element
(like "eth*") is a wildcard for a single name (like "eth1").
However, for match.kernel-command-line, the elements match individual
command line options, so we should have more flexibility of whether
a parameter is optional or mandatory. Extend the syntax for that.
- the elements can now be prefixed by either '|' or '&'. This makes
optional or mandatory elements, respectively. The entire match
evaluates to true if all mandatory elements match (if any) and
at least one of the optional elements (if any).
As before, if neither '|' nor '&' is specified, then the element
is optional (that means, "foo" is the same as "|foo").
- the exclamation mark is still used to invert the match. If used
alone (like "!foo") it is a shortcut for defining a mandatory match
("&!foo").
- the backslash can now be used to escape the special characters
above. Basically, the special characters ('|', '&', '!') are
stripped from the start of the element. If what is left afterwards
is a backslash, it also gets stripped and the remainder is the
pattern. For example, "\\&foo" has the pattern "&foo" where
'&' is no longer treated specially. This special handling of
the backslash is only done at the beginning of the element (after
the optional special characters). The remaining string is part
of the pattern, where backslashes might have their own meaning.
This change is mostly backward compatible, except for existing matches
that started with one of the special characters '|', '&', '!', and '\\'.
- mark global variables as const. This allows the linker to
mark the variable as read only.
- for nm_utils_wifi_[25]ghz_freqs(), don't generate a list based
on bg_table/a_table. Instead, keep static array of frequencies.
Since we have unit tests that check the consistency, this has
little maintenance effort.
- add unit tests
- in _keyfile_key_decode(), don't use GString. We know the maximum
string length before, so we can just allocated one buffer.
- in qdisc and tfilter writers, reuse the same GString instance.
No need to allocate a new temporary string buffer for each iteration.
- at other places, replace GString by NMStrBuf. This avoids the heap
allocated GString instance. Also, most operations can be inlined.
This results in larger code side, but avoids function calls to glib.
We want to parse "/proc/cmdline". That is space separated with support
for quoting and escaping. Our implementation becomes part of stable
behavior, and we should interpret the kernel command line the same way
as the system does. That means, our implementation should match
systemd's.
NMUtilsPredicateStr got introduced in 1.26.0 API. However, marking the typedef
to be available only in 1.26, causes a compiler warning when using the header:
/usr/include/libnm/nm-setting.h:372:39: error: ‘NMUtilsPredicateStr’ is deprecated: Not available before 1.26 [-Werror=deprecated-declarations]
372 | NMUtilsPredicateStr predicate);
| ^~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Avoid that. It's not a problem in practice, because all users of the typedef
are functions that are marked to be available in 1.26 themselves.
The API does not allow to distinguish between an unset (NULL) or empty
strv array. For example, nm_setting_match_get_paths() never returns
%NULL, but returns an empty strv array.
On the other hand, the GObject properties of type G_TYPE_STRV have a
default value of %NULL. That means, also the getter should map both
unset and empty to %NULL.
Note that this is a change in behavior w.r.t. 1.24.0 API, where
match.interface-name property would return an empty strv array.
Regrading the other API, this is no change because it is new API
and we will fix it before 1.26.0 release.
Iterating hash tables gives an undefined order. Often we want to have
a stable order, for example when printing the content of a hash or
when converting it to a "a{sv}" variant.
How to achieve that best? I think we should only iterate the hash once,
and not require additional lookups. nm_utils_named_values_from_strdict()
achieves that by returning the key and the value together. Also, often
we only need the list for a short time, so we can avoid heap allocating
the list, if it is short enough. This works by allowing the caller to
provide a pre-allocated buffer (usually on the stack) and only as fallback
allocate a new list.
Add a new "path" property to the match setting, which can be used to
restrict a connection to devices with a given hardware path. The new
property is a list of patterns that are matched against the ID_PATH
udev property of devices.
ID_PATH represents the topological persistent path of a device and
typically contains a subsystem string (pci, usb, platform, etc.) and a
subsystem-specific identifier. Some examples of paths are:
pci-0000:00:02.0
pci-0000:00:14.0-usb-0:5:1.0
platform-1c40000.ethernet
systemd-networkd also has a "Path=" option to match a device by udev
ID_PATH.
This does not match kernel behavior. You seem to be able to configure
multicast_snooping=auto,enabled with multicast_snooping off just fine.
Possibly this constrained was inspired by `ip link`, which says:
mcast_router MULTICAST_ROUTER - set bridge's multicast router if IGMP
snooping is enabled.
But kernel doesn't enforce this:
ip link delete br0 2>/dev/null; \
ip link add br0 type bridge mcast_router 1 mcast_snooping 0; \
grep ^ /sys/devices/virtual/net/br0/bridge/{multicast_router,multicast_snooping}
gives:
/sys/devices/virtual/net/br0/bridge/multicast_router:1
/sys/devices/virtual/net/br0/bridge/multicast_snooping:0
We probably should not implement additional constrains on top of what
kernel does, if the conditions are that obscure.
Fixes: e01d3b4c2b ('nm-setting-bridge: add 'multicast-router' bridge option')
Also, track sd_lldp_neighbor instance directly.
sd_lldp_neighbor is a perfectly reasonable container for keeping
track of the LLDP neighbor information. Just keep a reference to
it, and don't clone the data. Especially since the LLDP library
keeps a reference to this instance as well.
Also, to compare whether two neighbors are the same, it is sufficient
to only consider the raw data. Everything else depends on these fields
anyway.
This is only possible and useful becuase sd_lldp_neighbor is of course
immutable. It wouldn't make sense otherwise, but it also would be bad
design to mutate the sd_lldp_neighbor instances.
This couples our code slightly more to the systemd code, which we usually
try to avoid. But when we move away in the future from systemd LLDP library,
we anyway need to rework this heavily (and then too, we wouldn't want
to clone the data, when we could just share the reference).
Like the previous commit. Move code that depends on libnm-core out
of shared to avoid circular dependency.
Also add a readme file explaining the reason for existence of
the helper libraries nm-libnm-core-intern and nm-libnm-core-aux.
The "shared" directory is used by libnm-core, it should thus only depend on
code that is in the "shared" directory. Otherwise there is a circular
dependency, and meson's subdir() does not work nicely.
Also, libnm-core is really part of (and also an extension of) libnm-core,
so it belongs there.
I guess, the original idea was that this is also an extension for libnm,
so another project could take these utility functions (by copying them
into their source tree) and use them. That is still possible, it's
just that the sources are no longer under the shared directory.
Also add a readme to explain the non-obvious meaning of these files.
Originally, these files were part of libnm-core and linked together.
However, that is a licensing violation, because the code is GPL-2.0+
licensed, while libnm-core also gets linked with libnm (it must thus
be LGPL-2.1+). The original intent behind moving the code to "shared/"
was to avoid the licensing issue, but also to prepare when we would add
a separate, GPL licensed libnm-keyfile. However, currently we hope to
be able to relicense the code, so that it actually could be exposed as
part of libnm. This is work in progress at ([1]).
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/ ## 517
Anyway, the current directory layout is problematic. libnm-keyfile
depends on libnm-core, while libnm-core depends on code under shared.
That means, there is a circular dependency and meson's subdir() does
not work well.
Move the code.
When a device is not marked as unmanaged, but also not actively managed
by NetworkManager, then NetworkManager will generate an in-memory
profile to represent the active state, if the device is up and
configured (with an IP address).
Such profiles are commonly named like "eth0", and they are utterly
confusing to users, because they look as if NetworkManager actually
manages the device, when it really just shows that somebody else configures
the device.
We should express this better in the UI, hence add flags to indicate
that.
In practice, such profiles are UNSAVED, NM_GENERATED, and VOLATILE. But
add an explicit flag to represent that.
https://bugzilla.redhat.com/show_bug.cgi?id=1816202
The 'peer' property of ovs-patch is inserted into the 'options' column
of the ovsdb 'Interface' table. The ovs-vswitchd.conf.db man page says
about it:
options : peer: optional string
The name of the Interface for the other side of the patch. The
named Interface’s own peer option must specify this Interface’s
name. That is, the two patch interfaces must have reversed name
and peer values.
Therefore, it is wrong to validate the peer property as an IP address
and document it as such.
Fixes: d4a7fe4679 ('libnm-core: add ovs-patch setting')
Commit 37e7fa38c2 ("nm-supplicant-interface: enable OWE security
when transition mode is available") adds the OWE security flag in
case a valid OWE transtition mode IE is present on the beacon.
It also removes the OWE security flag in case the Iinformation elements
of a beacon are updated and a OWE transition mode IE can't be found.
When a pure OWE AP updates it's Information Elements (e.g. BSS Load
Element), the OWE security flag is falsely removed.
Introduce a new NM_802_11_AP_SEC_KEY_MGMT_OWE_TM security flag and use
it exclusively for OWE transition mode. Don't use the
M_802_11_AP_SEC_KEY_MGMT_OWE security flag on transition-mode APs.
Signed-off-by: David Bauer <mail@david-bauer.net>
nm_keyfile_read() and nm_keyfile_write() will be public API.
As such, it must be flexible and extendible for future needs.
There is already the handler callback that fully solves this
(e.g. a future handler event could request whether a certain
behavior is enabled or not).
As additional possibility for future extension, add a flags
argument. Currently no flags are implemented.
On Debian sid, libnss3-dev (2:3.53-1) causes a compiler warning:
In file included from ../libnm-core/nm-crypto-nss.c:13:
/usr/include/nss/pk11pub.h:951:1: error: function declaration isn't a prototype [-Werror=strict-prototypes]
951 | int SECMOD_GetSystemFIPSEnabled();
| ^~~
Iterating the hash gives the entries in undefined order. That
means, when validation would fail for more than one option,
then the error message arbitrarily points out one or the other.
Instead, process the entries in a defined order.
Note that nm_setting_ethtool_set_coalesce() used to coerce
"coalesce-adaptive-[rt]x" values to 0 or 1. The alternative
API doesn't do that. But so does nm_setting_option_set()
not tell you whether the value you set is valid. That is
not the options of the setters, for that we have verify().
