NMPowerMonitor emits the "shutdown" signal without arguments; fix the
definition of the signal.
Fixes: bd38a19832 ('connection: add support to down-on-poweroff')
Fix the following:
NetworkManager: file ../src/libnm-core-impl/nm-connection.c: line 321 (nm_connection_get_setting): should not be reached
NetworkManager.service: Main process exited, code=dumped, status=5/TRAP
Fixes: bd38a19832 ('connection: add support to down-on-poweroff')
Meson has shared_library and shared_module. The latter should be used
only for shared plugins loaded by dlopen, not for shared libraries
linked by the linker.
The target `nm_wwan` was defined as shared_module probably because it
is a library for loadable plugins only, andcontains references to
symbols from the main executable that cannot be resolved at link time.
Do as the deprecation message suggest and convert it to shared_library
with b_lundef=false:
DEPRECATION: target nm-device-plugin-wwan links against shared module nm-wwan, which is incorrect.
This will be an error in the future, so please use shared_library() for nm-wwan instead.
If shared_module() was used for nm-wwan because it has references to undefined symbols,
use shared_library() with `override_options: ['b_lundef=false']` instead.
The value can be unknown for different reasons:
- we don't have a value saved in NMDevice's "ip6_saved_properties"
because NM was restarted or because the device didn't have an
ifindex when it became managed.
- the value read from /proc is outside the allowed range (kernel
allows "echo 42 > /proc/sys/net/ipv6/conf/enp1s0/use_tempaddr")
Note that the second case was already possible before commit
797f3cafee ('device: fall back to saved use_tempaddr value instead
of rereading /proc').
If we can't determine the previous value, pass "unknown" to ndisc; it
will generate a l3cd with "unknown" ip6-privacy, which means to not
set the value when committing the configuration.
Fixes: 797f3cafee ('device: fall back to saved use_tempaddr value instead of rereading /proc')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1907
While enumerating devices at startup, we take a snapshot of existing
links from platform and we start creating device instances for
them. It's possible that in the meantime, while processing netlink
events in platform_link_added(), a link gets renamed. If that happens,
then we have two different views of the same ifindex: the cached link
from `links` and the link in platform.
This can cause issues: in platform_link_added() we create the device
with the cached name; then in NMDevice's constructor(), we look up
from platform the ifindex for the given name. Because of the rename,
this lookup can match a newly created, different link.
The end result is that the ifindex from the initial snapshot doesn't
get a NMDevice and is not handled by NetworkManager.
Fix this problem by fetching the latest version of the link from
platform to make sure we have a consistent view of the state.
https://issues.redhat.com/browse/RHEL-25808https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1897
When IPv6 privacy extensions are enabled, by default temporary addresses
have a valid lifetime of 1 week and a preferred lifetime of 1 day.
That's far too long for privacy-conscious users, some of whom want a new
address once every few seconds. Add connection options that correspond
to /proc/sys/net/ipv6/conf/*/temp_valid_lft and
/proc/sys/net/ipv6/conf/*/temp_prefered_lft to allow configuring the
address rotation time on a per-connection basis.
The new properties are defined as 32-bit signed integers to match the
sysctl parameters which are also signed, although currently only
positive numbers are valid.
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>
