When processing the rd.znet option set the interface name only in case when
the persistent interface names feature isn't disabled via net.ifnames=0
[lkundrak@v3.sk: minor tweaks to the net.ifnames=0 parsing]
The current solution for s390 specific details relies on an interface to
exist before adding the s390 details. It means the ip= option must precede
the rd.znet= option. Also only a single interface can be configured. With
this change the s390 details are put to the right interface and properly
named interface is created if it hasn't existed yet.
If the user adds an address manually, kernel automatically adds a
prefix route for it unless the address has the NOPREFIXROUTE
flag. When ip_config_merge_and_apply() gets called, NM also adds its
prefix route and so we end up with two routes that differ only for the
metric.
This is a problem because the route added by NM is not removed if the
user removes the previously added address. Also, it seems confusing to
have multiple instances of the same routes.
This commit skips the addition of a prefix route for addresses added
manually outside of NetworkManager.
Track whether IP addresses were added by NM or externally. In this way
it becomes possible in a later commit to add prefix route only for
addresses added by NM.
Allow a reapply of the connection when the device is still activating
and ensure that each reapply action is performed only at a given
activation stage. For example, the IP configuration is not reactivated
if the device is in the prepare stage.
https://bugzilla.redhat.com/show_bug.cgi?id=1763062
RFC does not define how long the client ID can be. However,
n-dhcp4 enforces that the server replies with a client ID that
matches the request. Also, the client ID gets encoded as a DHCP
option, hence it cannot be longer than 255 bytes.
While n-dhcp4 doesn't enforce a certain length, a too long client
ID is not going to work. Hence, truncate it at 133 bytes.
This is the same limit that also systemd's DHCP client has. It's chosen
to fit an RFC4361-complient client ID with a DUID of length
MAX_DUID_LEN (which is 128 bytes according to RFC 3315 section 9.1).
Fixes-test: @ipv4_set_very_long_dhcp_client_id
See-also: https://github.com/nettools/n-dhcp4/pull/6https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/307
The hostname used for DHCP can be the one obtained from the hostnamed
service and is not guaranteed to be valid, at least with systemd
239. Instead of sending an invalid DHCP option to the server or
failing due to later checks in clients, ignore the hostname and log a
warning when it is invalid.
https://bugzilla.redhat.com/show_bug.cgi?id=1744427
Note that the server always returns TRUE for the boolean return value
of ReloadConnections. Hence, this should not change in behavior, because
the server would never have returned FALSE.
However, change behavior of the API. It's odd that the function might
return %FALSE without setting the error output. It's also not clear
what the boolean value of the "ReloadConnections" D-Bus would mean
anyway.
If the 802.1X authentication fails and 802-1x.optional is set,
continue with activation. In this case, subscribe to the auth-state
supplicant property so that any dynamic IP method can be restarted
when the authentication succeeds. This is because upon authentication
the switch could have changed the VLAN we are connected to.
Refactor reading the phase2 authentication method for 802.1X.
Previously the reader only considered the first item of the
space-separated list; but since the 802.1x setting can hold distinct
phase2-auth and phase2-autheap properties - both mapped to the same
ifcfg-rh variable - we should parse the whole list. We only emit a
warning when multiple methods of the same type are found to avoid
breaking existing manually written ifcfg files.
Moreover, the reader implemented different checks for each of the
outer tunneled methods (PEAP, TTLS and FAST); drop those checks and
accept whatever the 802.1X setting also consider as valid. Note that
some combinations that are in principle valid, like PEAP + EAP-MD5,
were dropped before.
The pending action gets logged. We should not log plain pointer
values because they may be used to defeat ASLR.
Instead, construct the pending action using the "version_id". This
number is also unique, and suits sufficiently well. With debug logging
you can still grep the log for the corresponding active-connection (and
anyway it's obvious from the context).
These "pending-actions" only have one purpose: to mark the device
as busy and thereby delay "startup complete" to be reached. That
in turn delays "NetworkManager-wait-online" service.
Of course, "NetworkManager-wait-online" waits for some form of readiness
and is not extensively configurable (e.g. you cannot exclude devices from
being waited). However, the intent is to wait that all devices are "settled".
That means among others, that the timeouts waiting for carrier and Wi-Fi scan
results passed, and devices either don't have a connection profile to autoactivate,
or they autoactivated profiles and are in state "connected".
A major point here is that the device is considered ready, once it
reaches the state "connected". Note that if you configure both IPv4 and
IPv6 addressing modes, than "ipv4.may-fail=yes" and "ipv6.may-fail=yes"
means, that the device is considered fully activated once one address
family completes. Again, this is not very configurable, but by setting
"ipv6.may-fail=no", you can require that the device has indeed IPv6
addressing completed.
Now, the determining factor for declaring "startup complete" is whether the
device is in state "connected". That may or may not mean that DHCPv4,
autoconf or DHCPv6 completed, as it depends on a overall state of the
device. So, it is wrong to have distinct pending actions for these operations.
Remove them.
This fixes that we wrongly would wait too long before declaring startup
complete. But it is also a change in behavior.
We try to set only one time the MTU from the connection to not
interfere with manual user changes.
If at some point the parent interface changes temporarily MTU to a
lower value (for example, because the connection was reactivated), the
kernel will also lower the MTU on child interface and we will not
update it ever again.
Add a workaround to this. If we detect that the MTU we want to set
from connection is higher that the allowed one, go into a state where
we follow the parent MTU until it is possible to set again the desired
MTU. This is a bit ugly, but I can't think of any nicer way to do it.
https://bugzilla.redhat.com/show_bug.cgi?id=1751079
A MACsec connection doesn't have an ordering dependency with its
parent connection and so it's possible that the parent gets activated
later and sets a greater MTU than the original one.
It is reasonable and useful to keep the MACsec MTU configured by
default as the maximum allowed by the parent interface, that is the
parent MTU minus the encapsulation overhead (32). The user can of
course override this by setting an explicit value in the
connection. We already do something similar for VLANs.
https://bugzilla.redhat.com/show_bug.cgi?id=1723690
Introduce a generic function to set a MTU based on parent's one. Also
define a device-specific @mtu_parent_delta value that specifies the
difference from parent MTU that should be set by default. For VLAN it
is zero but other interface types (for example MACsec) require a
positive value due to encapsulation overhead.
Since commit 159ff23268 ('dhcp/dhclient-utils: skip over
dhclient.conf blocks') we skip blocks enclosed in lines containing '{'
and '}' because NM should ignore 'lease', 'alias' and other
declarations. However, conditional statements seem useful and should
not be skipped.
https://bugzilla.redhat.com/show_bug.cgi?id=1758550
PMF can be used with SAE, allow it. Actually, it is required according
to WPA3 specifications but there are implementations that don't
require it (hostapd can be configured in a such way); so let's not
make it mandatory for WPA3.
Fixes: 6640fb4b36 ('supplicant: add support for SAE key management')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/257
found by cppcheck
[src/devices/nm-device.c:3032] -> [src/devices/nm-device.c:3025]: (warning) Either the condition '!handle' is redundant or there is possible null pointer dereference: handle.
https://github.com/NetworkManager/NetworkManager/pull/352
The Bluetooth DUN device's NMModem would signal the reset of ifindex to zero
when it's disconnected and the NMDeviceBt would accordingly update the
bluetooth device's ip ifindex. This is not okay since commit ab4578302d
('device: refactor nm_device_set_ip_ifindex() and set_ip_iface()') which,
although claiming to be a refactoring, made such use of
nm_device_set_ip_ifindex() illegal. Resetting the ifindex is anyway not
necessary, since it's taken care of _cleanup_generic_post().
Let's leave the ifindex alone once the device is activated, in a manner
analogous to what NMDeviceModem.
Fixes: ab4578302d ('device: refactor nm_device_set_ip_ifindex() and set_ip_iface()')
Fixes: 78ca2a70c7 ('device: don't set invalid ip-iface'):
The devices tests' meson build files include only the build of a
single executable file and its execution as a test unit.
This has been moved to the devices' main meson build files so this
files can be removed.
In 878d4963e a new `nm-bt-test` helper program was added. However,
although `autotools` build steps were included, meson build steps
were not.
This add meson's build steps.
The test unit name string is used in different place so it has been
replaced by a variable.
The `nm-service-providers.c` source file is appended by using a
`files` generated object.
An extra variable is used for sources of
`libnm-settings-plugin-ifupdown` module. However, it only contains
one source file and using it directly avoiding the creation of the
extra variable doesn't hurt readibility.
The `ifcfg-rh` meson build file installs a new post install script
to create the `network-config` directory.
This has been moved to the main post install file so it's easier to
find because all post install steps are together and it avoids and
extra post install script execution.
The file has been fixed to be consistent with the rest of the files.
The data files to be installed have been grouped together. The
sourc files has been listed vertically and the link target in
`nm-settings-plugin-ifcfg-rh` does not use an array anymore.
The linker flags used when building `libnm_wwan` target uses an
array even when it only uses one value.
When using only one value the array is unnecessary so it has been
removed.
The set of c_flags used when building `ppp` targets has been grouped
together. Used dependencies have also been reviewed and removed
the unnecessary one.
Renamed the variable holding the compiler flags to be consistent
with different meson ports.
This naming pattern improves the use of different compiler flags
in environments with multiple languages.
