This is the same what kernel does, when the parent name is so long
that it would result in a too long overall name.
We need that the result is still a valid interface name.
(cherry picked from commit 1009f1f11f)
NetworkManager does not support changing the interface name for
infiniband interfaces. Consequently, we verify that
"connection.interface-name" is either unset or set to the expected
"$parent.$p_key". Anything else wouldn't work anyway and is rejected as
invalid configuration. That brings problems however.
Rejecting invalid configuration seems fine at first:
$ nmcli --offline connection add type infiniband infiniband.parent ib0 infiniband.p-key 0x8010 connection.interface-name xxx
Error: Error writing connection: connection.interface-name: interface name of software infiniband device must be 'ib0.8010' or unset (instead it is 'xxx')
However, when we modify the p-key, we also get an error message:
$ nmcli --offline connection add type infiniband infiniband.parent ib0 infiniband.p-key 0x8010 connection.interface-name ib0.8010 |
nmcli --offline connection modify infiniband.p-key 5
Error: Error writing connection: connection.interface-name: interface name of software infiniband device must be 'ib0.0005' or unset (instead it is 'ib0.8010')
It's worse, because ifcfg-rh reader will mangle the PKEY_ID with |=0x8000 to set
the full membership flag. That means, if you add a profile like
$ nmcli --offline connection add type infiniband infiniband.parent ib0 infiniband.p-key 0x0010 connection.interface-name ib0.0010
it gets written to ifcfg-rh file. Then upon reload it's invalid (as the
interface name mismatches).
There are multiple solutions for this. For example, ifcfg-rh reader could also
mangle the connection.interface-name, so that the overall result is valid. Or
we could just not validate at all, and accept any bogus interface-name.
With this patch instead we will just normalize the invalid configuration to
make it right.
$ nmcli --offline connection add type infiniband infiniband.parent ib0 infiniband.p-key 0x8010 connection.interface-name ib0.8010 |
nmcli --offline connection modify infiniband.p-key 5
...
The downside is that this happens silently, so a user doesn't
notice that configuration is ignored:
$ nmcli --offline connection add type infiniband infiniband.parent ib0 infiniband.p-key 0x8010 connection.interface-name foo
...
interface-name=ib0.8010
This approach still seems preferable, because setting
"connection.interface-name" for infiniband profiles makes little sense,
so what we care here is to avoid problems.
(cherry picked from commit 4610fd67e6)
Historically, initscripts' ifup-ib would set the highest bit of
PKEY_ID=. That changed and needs to be restored.
Note that it probably makes little sense to ever configure p-keys
without the highest bit set, because that flag indicates full membership
and kernel will automatically add it. At least, kernel will add the flag
for the p-key, but not for the automatically chosen interface name.
Meaning, writing 0x00f0 to create_child sysctl, results in an interface
"$parent.00f0", but `ip -d link` shows pkey 0x80f0.
As NetworkManager otherwise supports p-keys without the highest bit set,
and since that high bit is honored for the interface name, we cannot
just always add the high bit. NetworkManager always assuming the highest
bit is set, would change the interface names of existing configuration.
With this revert, when a user configures a small p-key and the profile
is stored in ifcfg-rh format, the settings backend will automatically
mangle the profile and set 0x8000. That is different from when the
profile is stored in keyfile format. Since using small p-keys is
probably an odd case, we don't try to workaround that any other way
(like that ifcfg format could represent the orignal value of the profile
and not doing such mangling, or to add the high bit throughout
NetworkManager to the p-key). It's an inconsistency, but given the
existing behaviors it seems best to stick (revert) to it.
This reverts commit a4fe16a426.
Affected versions were 1.42.2+ and 1.40.2+.
See-also: 05333c3602/f/rdma.ifup-ib (_75)https://bugzilla.redhat.com/show_bug.cgi?id=2209164
(cherry picked from commit f8e5e07355)
Currently if the IPv6 link-local address is removed after it passed
DAD, NetworkManager tries to generate a new link-local address. If
this fails, which is always the case for EUI64, ipv6ll is considered
as failed and the connection can go down (depending on may-fail).
This is particularly bad for virtual interfaces because if somebody
removes the link-local address, the activation can fail and destroy
the interface, breaking all services that require it. Also, it's a
change in behavior introduced in 1.36.0.
It seems that a better approach here is to re-add the address that was
removed externally.
[bgalvani@redhat.com: since the branch is missing commit 7ca95cee15
('platform: always reconfigure IP routes even if removed externally'),
we need to set flag NM_L3CFG_CONFIG_FLAGS_FORCE_ONCE when committing
the address, otherwise it's not re-added]
Fixes: aa070fb821 ('core: add NML3IPv6LL helper')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1622
(cherry picked from commit 53ba9f4701)
(cherry picked from commit 2976e4c3b7)
In constructed(), NMDevice starts watching the D-Bus name owner or
monitoring the unix socket, and so it is always aware if teamd is
running. When it is, NMDevice connects to it and initializes
priv->tdc.
It is not useful to try to connect to teamd in update_connection()
because warnings will be generated by NM and by libteam if teamd is
not running. As explained above the connection is always initialized
when teamd is available, and so we can just check priv->tdc.
Fixes: ab586236e3 ('core: implement update_connection() for Team')
https://bugzilla.redhat.com/show_bug.cgi?id=2182029https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1631
(cherry picked from commit 93430627c2)
(cherry picked from commit b60f0dd0a2)
Add per port priority support for bond active port re-selection during
failover. A higher number means a higher priority in selection. The
primary port still has the highest priority. This option is only
compatible with active-backup, balance-tlb and balance-alb modes.
(cherry picked from commit 2f0571f193)
(cherry picked from commit 748f6388aa)
sysfs is deprecated and kernel will not add new bond port options to
sysfs. Netlink is a stable API and therefore is the right method to
communicate with kernel in order to set the link options.
(cherry picked from commit bb435674b5)
(cherry picked from commit 1bce7f0dec)
If we're generating a connection for an externally configured slave,
refer the master by the UUID instead of the device name.
This doesn't matter most of the time. However, on a checkpoint restore
we need to make sure that a connection that is unambiguously the original
master is up.
Otherwise it could happen that a different connection was activated on the
same master device and the slaves being restored don't agree on which master
connection to bring up.
I can't think of any thing that would rely on this but I've been wrong
about more serious things before.
Fixes-test: @libnm_snapshot_reattach_unmanaged_ports_to_bridge
https://bugzilla.redhat.com/show_bug.cgi?id=2125615
(cherry picked from commit dc254f90e2)
There are many functions to replace properties of a link
(link_set_address, link_set_mtu, link_set_name, link_change,
etc.). Eventually, they will be replaced by a function that does
everything and removes all the code duplication.
That function will be named link_change(); rename the current
link_change() to link_change_extra().
(cherry picked from commit babe2bacd3)
(cherry picked from commit 9ae85f6541)
Fixes: e6a33c04eb ('all: make "ipv6.addr-gen-mode" configurable by global default')
(cherry picked from commit 48a3682a75)
(cherry picked from commit 987f98197b)
If the client was waiting for IPv6 DAD to complete and the lease was
updated or lost, `wait_ipv6_dad` needs to be cleared; otherwise, at
the next platform change the client will try to evaluate the DAD state
with a different or no lease. In particular if there is no lease the
client will try to decline it because there are no valid addresses,
leading to an assertion failure:
../src/core/dhcp/nm-dhcp-client.c:997:_dhcp_client_decline: assertion failed: (l3cd)
Backtrace:
__GI_raise ()
__GI_abort ()
g_assertion_message ()
g_assertion_message_expr ()
_dhcp_client_decline (self=0x1af13b0, l3cd=0x0, error_message=0x8e25e1 "DAD failed", error=0x7ffec2c45cb0) at ../src/core/dhcp/nm-dhcp-client.c:997
l3_cfg_notify_cb (l3cfg=0x1bc47f0, notify_data=0x7ffec2c46c60, self=0x1af13b0) at ../src/core/dhcp/nm-dhcp-client.c:1190
g_closure_invoke ()
g_signal_emit_valist ()
g_signal_emit ()
_nm_l3cfg_emit_signal_notify () at ../src/core/nm-l3cfg.c:629
_nm_l3cfg_notify_platform_change_on_idle () at ../src/core/nm-l3cfg.c:1390
_platform_signal_on_idle_cb () at ../src/core/nm-netns.c:411
g_idle_dispatch ()
Fixes: 393bc628ff ('dhcp: wait DAD completion for DHCPv6 addresses')
https://bugzilla.redhat.com/show_bug.cgi?id=2179890https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1594
(cherry picked from commit 24461954d0)
(cherry picked from commit 5019004bad)
F_SETFL will reset the flags. That is wrong, as we only want to add
O_NONBLOCK flag and leaving the other flags alone. Usually, we would
need to call F_GETFL first.
Note that on Linux, F_SETFL can only set certain flags, so the
O_RDWR|O_CLOEXEC flags were unaffected by this. That means, most likely
there are no other flags that our use of F_SETFL would wrongly clear.
Still, it's ugly, because it's not obvious whether there might be other
flags.
Avoid that altogether, by setting the flag already during open().
Fixes: 67e092abcb ('core: better handling of rfkill for WiMAX and WiFi (bgo #629589) (rh #599002)')
(cherry picked from commit 62a85fa845)
A "minor" release can still be the latest release. It depends
on which minor release you do. The script isn't smart enough
to understand the difference, so make the hint a bit clearer.
(cherry picked from commit 3c548dd081)
src/libnm-core-impl/tests/test-keyfile.c: In function '_invalid_option_write_handler':
src/libnm-core-impl/tests/test-keyfile.c:917:9: error: 'message' may be used uninitialized [-Werror=maybe-uninitialized]
917 | g_assert(message && strstr(message, "ethtool.bogus"));
| ^
src/libnm-core-impl/tests/test-keyfile.c:905:29: note: 'message' was declared here
905 | const char *message;
| ^
lto1: all warnings being treated as errors
(cherry picked from commit 8d6349156b)
(cherry picked from commit a71e51e712)
"wifi.seen-bssids" looks like a regular property, but it is not. Unlike
almost all other properties, it does not contain user configuration,
rather it gets filled by the daemon.
The values are thus stored in "/var/lib/NetworkManager/seen-bssids"
file, and the daemon maintains the values separately from the profile.
Only before exporting the profile on D-Bus, the value gets merged (see
NM_SETTINGS_CONNECTION_GET_PRIVATE(self)->>getsettings_cached and
nm_connection_to_dbus_full().
Hence, looking at nm_setting_wireless_get_num_seen_bssids() is not
working. Fix that.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1253
Fixes: 0f3203338c ('wifi: roam aggressively if we on a multi-AP network')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1577
(cherry picked from commit 07c6f933d1)
(cherry picked from commit 3ddc17700d)
Users can set `no-aaaa` DNS option to suppress AAAA queries made by the
stub resolver, including AAAA lookups triggered by NSS-based interfaces
such as getaddrinfo. Only DNS lookups are affected.
(cherry picked from commit 9d4bbf78f0)
(cherry picked from commit f71cd2eb72)
The present version of the EC2 metadata API (IMDSv2) requires a header
with a token to be present in all requests. The token is essentially a
cookie that's not actually a cookie that's obtained with a PUT call that
doesn't put anything. Apparently it's too easy to trick someone into
calling a GET method.
EC2 now supports IMDSv2 everywhere with IMDSv1 being optional, so let's
just use IMDSv2 unconditionally. Also, the presence of a token API can
be used to detect the AWS EC2 cloud.
https://bugzilla.redhat.com/show_bug.cgi?id=2151986
(cherry picked from commit 8b7e12c2d6)
(cherry picked from commit 429f36cd81)
Clarify that detect() needs to succeed before get_config().
I thought it's sort of common sense, but it's better to be explicit as
we're going to rely on that.
(cherry picked from commit 088bfd817a)
(cherry picked from commit d99864ccba)
We're going to extend those to issue methods other than GET.
Also, "request" would've been too long, "req" looks nicer.
(cherry picked from commit 85ce088616)
(cherry picked from commit 6e8cfbae32)
No need to do a deep clone. The strv array is not ever modified and we
pack it together in one memory allocation.
(cherry picked from commit 599fe234ea)
(cherry picked from commit 3787eacac9)
The compiler may dislike this:
CC src/core/platform/tests/libNetworkManagerTest_la-test-common.lo
In function '_ip_address_add',
inlined from 'nmtstp_ip4_address_add' at ../src/core/platform/tests/test-common.c:1892:5:
../src/core/platform/tests/test-common.c:1807:63: error: array subscript 'NMIPAddr {aka const struct _NMIPAddr}[0]' is partly outside array bounds of 'in_addr_t[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds]
1807 | peer_address->addr4,
| ~~~~~~~~~~~~^~~~~~~
../src/core/platform/tests/test-common.c: In function 'nmtstp_ip4_address_add':
../src/core/platform/tests/test-common.c:1886:36: note: object 'peer_address' of size 4
1886 | in_addr_t peer_address,
| ~~~~~~~~~~~~^~~~~~~~~~~~
...
Fixes: 06aafabf14 ('platform/test: add test adding IPv4 addresses that only differ by their peer-address')
(cherry picked from commit 40dd8bf93a)
(cherry picked from commit adca87aba9)
We must first check whether a->arp_ip_targets_num and
b->arp_ip_targets_num are identical. Otherwise, this accesses
potentially uninitialized values.
Fixes: f900f7bc2c ('platform: add netlink support for bond link')
(cherry picked from commit 8dd18d91b2)
(cherry picked from commit c543c7f9d7)
We just lookup the link info by ifindex. There is no guarantee that that
ifindex is of the expected type, to have a suitable ext-data. Check for
that.
Fixes: a7d2cad67e ('platform/linux: add support for WPAN links')
(cherry picked from commit 6dafe78088)
(cherry picked from commit ae1c4f45ad)
