A common source for doubts and questions from users is about why
devices are unmanaged. Unfortunately NM doesn't expose that
information properly via D-Bus and so it's not available in nmcli.
The device D-Bus object has two properties that are strictly related:
"state" and "state-reason". The latter represents the reason for the
current state. Introduce new reasons to indicate the possible causes
for the unmanaged state. Note that a device can be unmanaged because
of multiple reasons at the same time, we only return one.
Before:
$ nmcli -f GENERAL.DEVICE,GENERAL.TYPE,GENERAL.STATE,GENERAL.reason device show
GENERAL.DEVICE: enp7s0
GENERAL.TYPE: ethernet
GENERAL.STATE: 10 (unmanaged)
GENERAL.REASON: 0 (No reason given)
GENERAL.DEVICE: tun0
GENERAL.TYPE: tun
GENERAL.STATE: 10 (unmanaged)
GENERAL.REASON: 0 (No reason given)
GENERAL.DEVICE: hwsim0
GENERAL.TYPE: unknown
GENERAL.STATE: 10 (unmanaged)
GENERAL.REASON: 0 (No reason given)
After:
$ nmcli -f GENERAL.DEVICE,GENERAL.TYPE,GENERAL.STATE,GENERAL.reason device show
GENERAL.DEVICE: enp7s0
GENERAL.TYPE: ethernet
GENERAL.STATE: 10 (unmanaged)
GENERAL.REASON: 76 (The device is unmanaged by user decision via settings plugin ("unmanaged-devices" for keyfile or "NM_CONTROLLED=no" for ifcfg-rh))
GENERAL.DEVICE: tun0
GENERAL.TYPE: tun
GENERAL.STATE: 10 (unmanaged)
GENERAL.REASON: 75 (The device is unmanaged by explicit user decision (e.g. 'nmcli device set $DEV managed no')
GENERAL.DEVICE: hwsim0
GENERAL.TYPE: unknown
GENERAL.STATE: 10 (unmanaged)
GENERAL.REASON: 69 (The device is unmanaged because the device type is unmanaged by default)
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1887
Setting for wpa_supplicant openssl_ciphers - openssl sometimes moves
ciphers among SECLEVELs. That is generaly a good thing, but some servers
are too old to support newer ciphers. Thus expert user should be allowed
to define openssl_ciphers per connection, so that they can connect to
old server, while not compromising security of other connections.
When creating VLAN over OVS internal interface which holding the same
name as its controller OVS bridge, NetworkManager will fail with error:
Error: Connection activation failed: br0.101 failed to create
resources: cannot retrieve ifindex of interface br0 (Open vSwitch
Bridge)
Expanded the `find_device_by_iface()` with additional argument
`child: NmConnection *` which will validate whether candidate is
suitable to be parent device.
In `nm_device_check_parent_connection_compatible()`, we only not allow OVS
bridge and OVS port being parent.
Resolves: https://issues.redhat.com/browse/RHEL-26753
Signed-off-by: Gris Ge <fge@redhat.com>
With `NM_CHECKPOINT_CREATE_FLAG_TRACK_INTERNAL_GLOBAL_DNS` flag set on
checkpoint creation, the checkpoint rollback will restore the
global DNS in internal configure file
`/var/lib/NetworkManager/NetworkManager-intern.conf`.
If user has set global DNS in /etc folder, this flag will not take any
effect.
Resolves: https://issues.redhat.com/browse/RHEL-23446
Signed-off-by: Gris Ge <fge@redhat.com>
Introduce a new option to NMSettingIpConfig. The new option is ternary
type being the default value set to disabled. When enabled,
NetworkManager will instruct the DHCP client to send RELEASE message
when IP addresses are being removed.
The argument might imply that when set to FALSE, the dhcp client won't
send a RELEASE message. This won't be true with the new
dhcp-send-release option that is going to be introduced.
Instead, change the name to "force_release", when set to TRUE it means
we are sending a RELEASE message even if not indicated by the user. When
set to FALSE, it will be up to the user.
The new option at NMSettingConnection allow the user to specify if the
connection needs to be down when powering off the system. This is useful
for IP address removal prior powering off. In order to accomplish that,
we listen on "Shutdown" systemd DBus signal.
The option is set to FALSE by default, it can be specified globally on
configuration file or per profile.
The code that is adding the devices to the sleeping list and taking them
down should be moved to a separated function. This way we can reuse it
and we avoid duplicating code.
In order to provide the NMSleepMonitor a more generic usage, let's
rename the whole module to NMPowerMonitor. Nothing is exposed to the API
so it is a trivial renaming.
Disable the vlan_xgress unit test which was failing.
This test is currently being work and is going to be fixed soon.
(cherry picked from commit 6e30e37ebe)
If a generic device is present and the name matches, it is compatible
with any link type.
For example, if a generic connection has a device-handler that creates
a dummy interface, the link is compatible with the NMDeviceGeneric.
When a generic connection has a custom device-handler, it always
generates a NMDeviceGeneric, even when the link that gets created is
of a type natively supported by NM. On service restart, we need to
keep track that the device is generic or otherwise a different device
type will be instantiated.
If the device-handler of the generic connection is set, the connection
is virtual and the device is created by invoking the device-handler
via NetworkManager-dispatcher service.
With this change, a generic device now represents two different device
classes:
- existing interfaces that are not natively supported or recognized
by NetworkManager. Those devices have the `has_device_handler`
property set to FALSE;
- interfaces that are created by NM by invoking the device-handler;
they have `has_device_handler` set to TRUE.
Device handlers need a way to pass data back to NetworkManager, such
as the ifindex and an error message. Allow them to return a dictionary
on standard output, where each line contains a "$key=$value" pair.
In the daemon, the dictionary is returned via the callback function.
"device-add" and "device-delete" actions are called for
device-handlers of generic devices. They differ from other actions in
the following aspects:
- only one script is invoked, the one with name specified by the
device-handler property;
- the script is searched in the "device" subdirectory;
- since there is only one script executed, the result and error
string from that script are returned by NM in the callback function.
Call the Action2() method first, and fall back to the old Action() if
the new one is not available. This allows full interoperability
between different versions of the dispatcher service and NM.
Move common code from nm_dispatcher_call_device() and
nm_dispatcher_call_device_sync() to a new function; it will also be
used in the next commits by a new variant of the function.
Set these parameters according to the values set in the new properties
sriov.eswitch-inline-mode and sriov.eswitch-encap-mode.
The number of parameters related to SR-IOV was becoming too big.
Refactor to group them in a NMPlatformSriovParams struct and pass it
around.
Background: when router sends router advertisement (RA) message,
NetworkManager processes it and passes data to a lower system layer.
Currently there is a problem that NetworkManager adds one second to both
valid lifetime and preferred lifetime. This happens because of the
algorithm in nm_ndisc_data_to_l3cd() function.
Let's look at an example: let current timestamp be 100450, so now_sec
variable is 100. At this moment RA message was received from the router.
The IPv6 address' valid lifetime is 200 seconds (for example), so
expiration timestamp (ndisc_addr->expiry_msec) is 300450. But after the
_nm_ndisc_lifetime_from_expiry() call, NMPlatformIP6Address lifetime
becomes 201 ((300450-(100*1000)+999)/1000). Which is wrong.
This commit fixes this behaviour by replacing
nm_utils_get_monotonic_timestamp_sec() with
nm_utils_get_monotonic_timestamp_msec() so that timestamps are
calculated more precisely.
Related issue: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1464
Merge request: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1863
When the lease is lost, NM tries to get a new by restarting the DHCP
transaction. However, it doesn't delete the existing l3cds (one from
the DHCP client with flag ONLY_FOR_ACD, the other from
NMDevice). Therefore, the l3cfg still tracks the ACD state of the
address as "external-removed", and when NM gets the same address via
DHCP, ACD is considered as failed; as a consequence, NM sends a
DECLINE message to the server.
Moreover, the l3cd added by NMDevice for DHCP has a zero ACD timeout,
and so it's not possible to do ACD again on the same address.
Remove those l3cds when the lease expires, so that any ACD state is
cleared and DHCP can perform ACD again.
Fixes: 240ec7f891 ('dhcp: implement ACD (address collision detection) for DHCPv4')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1853
The main change is that lease address and pd getters changed and the new
functions are now used.
In addition, solved several conflicts due to disabled code and added
adapt header to new files.
GKeyfile changed something about how to handle invalid escape sequences.
As we don't want to test GKeyfile (per-se), just adjust to test to not
hit the problem.
This would fail with glib2-2.79.1-1.fc40:
# ./tools/run-nm-test.sh -m src/core/tests/config/test-config -p /config/set-values
TAP version 13
# random seed: R02Sb8afff1ec38ca5a1b7713e8c40eb4f56
# Start of config tests
# GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation local (GLocalVfs) for ?gio-vfs?
# (src/core/tests/config/test-config.c:1107) invalid value in config-data .intern.with-whitespace.key2 = (null) (instead of " b c\, d ")
./tools/run-nm-test.sh: line 307: 245847 Trace/breakpoint trap (core dumped) "${NMTST_DBUS_RUN_SESSION[@]}" "$TEST" "${TEST_ARGV[@]}"
exec "src/core/tests/config/test-config" failed with exit code 133
When doing reapply on linux bridge interface, NetworkManager will reset
the VLAN filtering and default PVID which cause PVID been readded to all
bridge ports regardless they are managed by NetworkManager.
This is because Linux kernel will re-add PVID to bridge port upon the
changes of bridge default-pvid value.
To fix the issue, this patch introduce netlink parsing code for
`vlan_filtering` and `default_pvid` of NMPlatformLnkBridge, and use that
to compare desired VLAN filtering settings, skip the reset of VLAN
filter if `default_pvid` and `vlan_filtering` are unchanged.
Signed-off-by: Gris Ge <fge@redhat.com>
Currently the internal DHCP client sets traffic class "CS6" in the DS
field of the IP header for outgoing packets.
dhclient sets the field according to the definition of TOS (RFC 1349),
which was was deprecated in 1998 by RFC 2474 in favor of DSCP.
Introduce a new property IPvX.dhcp-dscp (currently valid only for
IPv4) to specify a custom DSCP value for DHCP backends that support it
(currently, only the internal one).
Define the default value to CS0, because:
- section 4.9 of RFC 4594 specifies that DHCP should use the standard
(CS0 = 0) service class;
- section 3.2 says that class CS6 is for "transmitting packets
between network devices (routers) that require control (routing)
information to be exchanged between nodes", listing "OSPF, BGP,
ISIS, RIP" as examples of such traffic. Furthermore, it says that:
User traffic is not allowed to use this service class. By user
traffic, we mean packet flows that originate from user-controlled
end points that are connected to the network.
- we got reports of some Cisco switches dropping DHCP packets because
of the CS6 marking.
As done for IPv4 in commit 3b145a33b7 ('vpn-connections: allow the
plugin to specify route preferred src'), allow VPN plugins to return a
preferred source address for routes. Still accept the old format.
The decision to configure or not configure routes without addresses only
related to what method is configured - DHCP and non-DHCP cases. For DHCP
case, the deamon waits until addresses appear first before configuring
the static routes to preserve the behavior mentioned in
https://bugzilla.redhat.com/show_bug.cgi?id=2102212, otherwise, the
daemon can configure the routes immediately for non-DHCP case.
If a generated connection matches a connection that uses interface name
as controller, we need to drop the existing value from the settings to
avoid conflicts. Therefore, both of them need to be dropped; controller
and master.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1833
Fixes: 3e4a2ebb3c ('all: use the new NMSettingConnection Controller property')
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
Mark the methods/properties deprecated in the D-Bus API (via
org.freedesktop.DBus.Introspectable.Introspect(), [1]).
It affects those properties that are documented as deprecated in
introspection XML.
$ busctl -j call \
org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager \
org.freedesktop.DBus.Introspectable \
Introspect | \
jq '.data[0]' -r | \
grep -5 Deprecated
[1] https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-introspectable
A IPv4 conflict detected during the probe is a serious problem, as it
prevents the address from being configured. As such, is should be
displayed at warning level.
A conflict detected after the address is already configured
(addr_info->state == NM_L3_ACD_ADDR_STATE_CONFLICT) is less important
because NM will try to defend the address and will keep using it.
