mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2025-12-28 18:00:10 +01:00
cb73ae3f0b
Infiniband profiles can have a p-key set. Both in kernel API
("create_child" sysctl) and in NetworkManager API, that key can range
from 0x0001 to 0xFFFF (0x8000 excluded). NetworkManager does not support
renaming the interface, so kernel always assigns the interface name
"$PHYSDEV.$PKEY_ID" (with $PKEY_ID as 4 character hex digits).
Note that the highest bit in the p-key (0x8000) is the full-membership
flag. Internally, kernel only supports full-membership so when we create
for example "ib0.00c1" and "ib0.80c1" interfaces, their actually used
p-key is in both cases 0x80c1 and you can see it with `ip -d link`.
Nonetheless, kernel and NetworkManager allow to configure the p-key
without the highest bit set, and the result differs in the interface
name.
Note that initscripts' ifup-ib0 would always internally coerce the
PKEY_ID variable to have the high bit set ([1]). It also would require
that the `DEVICE=` variable is specified and matches the expected
interface name. So both these configurations are identical and valid:
DEVICE=ib0.80c1
PHYSDEV=ib0
PKEY_ID=0x80c1
and
DEVICE=ib0.80c1
PHYSDEV=ib0
PKEY_ID=0x00c1
Historically, NetworkManager would also implement the same restrictions
([2], [3], [4]). That meant, not all valid NetworkManager infiniband
profiles could be expressed as ifcfg file. For example, NetworkManager
allows to have "connection.interface-name" (`DEVICE=`) unset (which
ifup-ib and ifcfg reader did not allow). Also, NetworkManager would
allow configuring a "infiniband.p-key" without full membership flag, and
the reader would mangle that.
This caused various problems to the point that when you configure an
infiniband.p-key with a non-full-membership key, the ifcfg-rh written by
NetworkManager was invalid. Either, you could leave
"connection.interface-name" unset, but then the reader would complain
about missing `DEVICE=`. Or, we could write `DEVICE=ib0.00c1;
PKEY_ID=0x00c1`, which was invalid as we expected `DEVICE=ib0.80c1`.
This was addressed by rhbz 2122703 ([5]). The fix was to
- not require a `DEVICE=` ([6]).
- don't mangle the `PKEY_ID=` in the reader ([7]).
which happened in 1.41.2 and 1.40.2 (rhel-8.8).
With this change, we could persist any valid infiniband profile to ifcfg
format. We also could read back any valid ifcfg file that NetworkManager
would have written in the past (note that it could not write valid ifcfg
files previously, if the p-key didn't have the full-membership key set).
The problem is, that users were used to edit ifcfg files by hand, and
users would have files with:
DEVICE=ib0.80c1
PHYSDEV=ib0
PKEY_ID=0x00c1
This files had worked before, but now failed to verify as we would
expect `DEVICE=ib0.00c1`. Also, there was a change in behavior that
PKEY_ID is now interpreted without the high bit set. This is reported as
rhbz 2209164 ([8]).
We will do several things to fix that:
1) we now normalize the "connection.interface-name" to be valid. It was
not useful to set it anyway, as it was redundant. Complaining about a
redundant setting, which makes little sense to configure, is not useful.
This is done by [9].
2) we now again treat PKEY_ID= as if it had 0x8000 flag set. This was done by
[10].
With step 1) and 2), we are able to read any existing ifcfg files out
there in the way we did before 1.41.2.
There is however one piece missing. When we now create a profile using
nmcli/libnm/D-Bus, which has a non-full-membership p-key, then the
profile gets mangled in the process.
If the user uses NetworkManager API to configure an interface and
chooses a non-full-membership p-key, then this should work the same as
with keyfile plugin (or on rhel-9, where keyfile is the default). Note
that before 1.41.2 it didn't work at all, when the user used ifcfg-rh
backend. Likely(?) there are no users who rely on creating such a profile
with nmcli/libnm/D-Bus and expect to automatically have the p-key
normalized. That didn't work before 1.41.2 and didn't behave that way
between 1.41.2 and now.
This patch fixes that by introducing a new key PKEY_ID_NM= for holding
the real p-key. Now ifcfg backend is consistent with handling infiniband
profiles, and old, hand-written ifcfg files still work as before.
There is of course change in behavior, that ifcfg files between 1.41.2
and now were interpreted differently. But that is bug 2209164 ([8]) and
what we fix here.
For now strong reasons, we keep writing the PKEY_ID to file too. It's
redundant, but that is what a human might expect there.
[1]
|
||
|---|---|---|
| .. | ||
| tests | ||
| meson.build | ||
| nm-connection-private.h | ||
| nm-connection.c | ||
| nm-dbus-utils.c | ||
| nm-default-libnm-core.h | ||
| nm-errors.c | ||
| nm-keyfile-utils.c | ||
| nm-keyfile.c | ||
| nm-meta-setting-base-impl.c | ||
| nm-property-compare.c | ||
| nm-property-compare.h | ||
| nm-setting-6lowpan.c | ||
| nm-setting-8021x.c | ||
| nm-setting-adsl.c | ||
| nm-setting-bluetooth.c | ||
| nm-setting-bond-port.c | ||
| nm-setting-bond.c | ||
| nm-setting-bridge-port.c | ||
| nm-setting-bridge.c | ||
| nm-setting-cdma.c | ||
| nm-setting-connection.c | ||
| nm-setting-dcb.c | ||
| nm-setting-dummy.c | ||
| nm-setting-ethtool.c | ||
| nm-setting-generic.c | ||
| nm-setting-gsm.c | ||
| nm-setting-hostname.c | ||
| nm-setting-infiniband.c | ||
| nm-setting-ip-config.c | ||
| nm-setting-ip-tunnel.c | ||
| nm-setting-ip4-config.c | ||
| nm-setting-ip6-config.c | ||
| nm-setting-macsec.c | ||
| nm-setting-macvlan.c | ||
| nm-setting-match.c | ||
| nm-setting-olpc-mesh.c | ||
| nm-setting-ovs-bridge.c | ||
| nm-setting-ovs-dpdk.c | ||
| nm-setting-ovs-external-ids.c | ||
| nm-setting-ovs-interface.c | ||
| nm-setting-ovs-patch.c | ||
| nm-setting-ovs-port.c | ||
| nm-setting-ppp.c | ||
| nm-setting-pppoe.c | ||
| nm-setting-private.h | ||
| nm-setting-proxy.c | ||
| nm-setting-serial.c | ||
| nm-setting-sriov.c | ||
| nm-setting-tc-config.c | ||
| nm-setting-team-port.c | ||
| nm-setting-team.c | ||
| nm-setting-tun.c | ||
| nm-setting-user.c | ||
| nm-setting-veth.c | ||
| nm-setting-vlan.c | ||
| nm-setting-vpn.c | ||
| nm-setting-vrf.c | ||
| nm-setting-vxlan.c | ||
| nm-setting-wifi-p2p.c | ||
| nm-setting-wimax.c | ||
| nm-setting-wired.c | ||
| nm-setting-wireguard.c | ||
| nm-setting-wireless-security.c | ||
| nm-setting-wireless.c | ||
| nm-setting-wpan.c | ||
| nm-setting.c | ||
| nm-simple-connection.c | ||
| nm-team-utils.c | ||
| nm-team-utils.h | ||
| nm-utils-private.h | ||
| nm-utils.c | ||
| nm-vpn-editor-plugin.c | ||
| nm-vpn-plugin-info.c | ||
| README.md | ||
libnm-core-impl
NetworkManager provides a client library libnm.
NetworkManager core does not (dynamically) link against all of libnm.
Instead, it statically links against a part of it.
That part is the static helper library libnm-core-impl.
libnm-core-impl implements (and provides) the API from
libnm-core-public, which is part of the public
API of libnm. In this form, libnm-core-impl is part
of the implementation of libnm. It also implements (and
provides) an internal API libnm-core-intern which
can only be used by those who link statically against libnm-core-impl.
Only NetworkManager core and libnm are allowed to statically
link with libnm-core-impl. Consequently, only those are allowed to include
libnm-core-intern.
This directory should not be added to the include search path of other
components as they are only allowed to include libnm-core-public
and libnm-core-intern.