Adds an option in the connectivity section to change the timeout before
the interface is deemed "limited". Previously, it was hardcoded to
20 seconds, but for our usecase (failing over to cell modem if
hardwired ethernet drops), it's nice to be able to failover to another
interface more quickly.
The OVS interface can be matched via MAC address; in that case, the
"connection.interface-name" property of the connection is empty.
When populating the ovsdb, we need to pass the actual interface name
from the device, not the one from the connection.
Fixes: 830a5a14cb ('device: add support for OpenVSwitch devices')
https://issues.redhat.com/browse/RHEL-34617
Note: here I refer to the numbers in a version as MAJOR.MINOR.MICRO.
Having stable and development releases do make sense for the MINOR
version, because we maintain separate branches for them and they
evolve separately. We have 1.47.z where we put all the changes so
anyone can pick the latest development release and test it. At the
same time, we have 1.46.z with the latest stable released version.
However, it does not make sense to have 1.46.2 and 1.46.3-dev because
the latter is not a development version. It is identical to 1.46.2,
only the version number has been bumped, there are no changes to test.
When we add commits, we will be actually testing 1.46.3-dev + some
commits, which is exactly the same as testing 1.46.2 + some commits.
So, basically, someone can use the releases of a development BRANCH,
like 1.47.4, to test the development version of NM. But using a
development MICRO version is exactly the same as using a
non-development one.
From now on, we will just increment the MICRO version each time we do a
release on a stable branch and won't create the '-dev' tag. Update
release.sh to do it this way.
We are planning on completely dropping Autotools in the future.
This breaks the build process with an argument to ignore the deprecation,
so that anyone building NM is warned of this change.
If a connection is in-memory (i.e. has flag "unsaved"), after a
checkpoint and rollback it can be wrongly persisted to disk:
- if the connection was modified and written to disk after the
rollback, during the rollback we update it again with persist mode
"keep", which keeps it on disk;
- if the connection was deleted after the rollback, during the
rollback we add it again with persist mode "to-disk".
Instead, remember whether the connection had the "unsaved" flag set
and try to restore the previous state.
However, this is not straightforward as there are 4 different possible
states for the settings connection: persistent; in-memory only;
in-memory shadowing a persistent file; in-memory shadowing a detached
persistent file (i.e. the deletion of the connection doesn't delete
the persistent file). Handle all those cases.
Fixes: 3e09aed2a0 ('checkpoint: add create, rollback and destroy D-Bus API')
When we recibe a Netlink message with a "route change" event, normally
we just ignore it if it's a route that we don't track (i.e. because of
the route protocol).
However, it's not that easy if it has the NLM_F_REPLACE flag because
that means that it might be replacing another route. If the kernel has
similar routes which are candidates for the replacement, it's hard for
NM to guess which one of those is being replaced (as the kernel doesn't
have a "route ID" or similar field to indicate it). Moreover, the kernel
might choose to replace a route that we don't have on cache, so we know
nothing about it.
It is important to note that we cannot just discard Netlink messages of
routes that we don't track if they has the NLM_F_REPLACE. For example,
if we are tracking a route with proto=static, we might receive a replace
message, changing that route to proto=other_proto_that_we_dont_track. We
need to process that message and remove the route from our cache.
As NM doesn't know what route is being replaced, trying to guess will
lead to errors that will leave the cache in an inconsistent state.
Because of that, it just do a cache resync for the routes.
For IPv4 there was an optimization to this: if we don't have in the
cache any route candidate for the replacement there are only 2 possible
options: either add the new route to the cache or discard it if we are
not interested on it. We don't need a resync for that.
This commit is extending that optimization to IPv6 routes. There is no
reason why it shouldn't work in the same way than with IPv4. This
optimization will only work well as long as we find potential candidate
routes in the same way than the kernel (comparing the same fields). NM
calls to this "comparing by WEAK_ID". But this can also happen with IPv4
routes.
It is worth it to enable this optimization because there are routing
daemons using custom routing protocols that makes tens or hundreds of
updates per second. If they use NLM_F_REPLACE, this caused NM to do a
resync hundreds of times per second leading to a 100% CPU usage:
https://issues.redhat.com/browse/RHEL-26195
An additional but smaller optimization is done in this commit: if we
receive a route message for routes that we don't track AND doesn't have
the NLM_F_REPLACE flag, we can ignore the entire message, thus avoiding
the memory allocation of the nmp_object. That nmp_object was going to be
ignored later, anyway, so better to avoid these allocations that, with
the routing daemon of the above's example, can happen hundreds of times
per second.
With this changes, the CPU usage doing `ip route replace` 300 times/s
drops from 100% to 1%. Doing `ip route replace` as fast as possible,
without any rate limitting, still keeps NM with a 3% CPU usage in the
system that I have used to test.
This allows SLAAC for IPv6 to be performed, even when no IPv6
address was passed by the bearer. The link-local address will be
assigned, because of do_auto = TRUE.
The commit also allows the DNS assignment to be made statically when
no IPv6 address has been statically assigned yet. This is to be able
to receive IPv6 DNS servers via signalling, where host SLAAC still
needs to be performed for some modems (e.g. some huawei modems).
This also changes the logging so that SLAAC usage is logged
on a separate line.
Command NL80211_CMD_GET_WIPHY without any flag only returns channels
in the 2 GHz and 5 GHz bands, for backwards compatibility with old
userspace tools. To get the full list we need to pass attribute
NL80211_ATTR_SPLIT_WIPHY_DUMP (added in Linux 3.9 released in 2013),
and allow the handler to be called multiple times.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1500
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
Note that some of those sandboxing options may require relatively
recent systemd. In that case, to run against older systemd, you
will need to patch the service file. I don't think there is
a way around that, and limiting outselves to only the oldest supported
option is harmful for users who run recent systemd.
See-also: https://fedoraproject.org/wiki/Changes/SystemdSecurityHardening
Users should not be allowed to start or stop a wifi-p2p scan unless
they have some kind of permission. Since we already have the
"org.freedesktop.NetworkManager.wifi.scan" permission for wifi scans,
check that.
Fixes: dd0c59c468 ('core/devices: Add DBus methods to start/stop a P2P find')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1795
It doesn't scale to export all addresses/routes on D-Bus as properties.
In particular not combined with PropertiesChanged signal. On a busy
system, this causes severe performance issues. It also doesn't seem very
useful. Routes and addresses are complex things (e.g. policy routing).
If you want to do anything serious, you must check netlink (or find
another way to get the information).
Note that NMPlatform already ignores routes of certain protocols
(ip_route_is_alive()). It also does not expose most route attributes,
making the output only useful for very limited cases (e.g. displaying to
the user for information).
Limit the number of exported entries to 100.
Try adding 100K routes one-by-one. Run a `nmcli monitor` instance.
Re-nice the nmcli process and/or keep the CPUs busy. Then start a script
that adds 100k routes. Observe. Glib's D-Bus worker thread receives the
messages and queues them for the main thread. The main thread is too
slow to process them, the memory consumption grows very quickly in Giga
bytes. Afterwards, the memory also is not returned to the operation
system, either because of fragmentation or because the libc allocator
does anyway not return heap memory.
It doesn't work to expose an unlimited number of objects on D-Bus. At
least not with an API, that sends the full list of all routes, whenever
a route changes. Nobody can use that feature either, because the only
use is a quick overview in `nmcli` output or a GUI. If you see 100+
routes there, that becomes unmanageable anyway. Instead use netlink if
you want to handle the full list of addresses/routes (or some other
API).
If you add a large number of addresses/routes, then the output of
`nmcli` is unusable. It also doesn't seem too useful.
Limit the number to show up to 10 addresses and 10 routes.
If there are more than 10 addresses, then print an 11th line with
inet4 ... N more
Actually, if there are exactly 11 addresses, then don't waste an extra
line to print "1 more". Instead, still print the 11th address. Same for
routes.
Add a new "stable-ssid" mode that generates the MAC address based on the
Wi-Fi's SSID.
Note that this gives the same MAC address as setting
connection.stable-id="${NETWORK_SSID}"
wifi.cloned-mac-address="stable"
The difference is that changing the stable ID of a profile also affects
"ipv6.addr-gen-mode=stable-privacy" and other settings.
For Wi-Fi profiles, this will encode the SSID in the stable-id.
For other profiles, this encodes the connection UUID (but the SSID and
the UUID will always result in distinct stable IDs).
Also escape the SSID, so that the generated stable-id is always valid
UTF-8.
Now that we no longer test on CentOS7, we also have no more tests that
build using Python2.
Note that build with Python2 is currently broken already (which would be
fixable).
Drop Python2 too.
Existing Python scripts still use a common subset of Python2 and
Python3. They can be improved to use Python3 features in the future.
If ID_NET_MANAGED_BY= attribute is set, we have an indication who is
responsible for the device. If this is set to anything but
"org.freedesktop.NetworkManager", then the device is unmanaged.
The effect is the same as setting NM_UNMANAGED= attribute. NM_UNMANAGED=
takes precedence over this setting.
See-also: https://github.com/systemd/systemd/issues/29768
See-also: https://github.com/systemd/systemd/pull/29782
We honored "NM_AUTO_DEFAULT_LINK_LOCAL_ONLY" udev property, for when we
generate a "Wired connection 1" (aka the "auto-default connection").
Systemd now also honors and may set ID_NET_AUTO_LINK_LOCAL_ONLY for
a similar purpose. Honore that too.
The NM specific variable still is preferred, also because "NM_AUTO_DEFAULT_LINK_LOCAL_ONLY"
is about something very NetworkManager specific (controlling "Wired connection 1").
Maybe one day, we should drop "data/90-nm-thunderbolt.rules" and only
rely on what systemd provides. But not yet.
See-also: https://github.com/systemd/systemd/pull/29767https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1413
Historically, the NMSetting types were in public headers. Theoretically,
that allowed users to subtype our classes. However in practice that was
impossible because they lacked required access to internal functions to
fully create an NMSetting class outside of libnm. And it also was not
useful, because you simply cannot extend libnm by subtyping a libnm
class. And supporting such a use case would be hard and limit what we can
do in libnm.
Having GObject structs in public headers also require that we don't
change it's layout. The ABI of those structs must not change, if anybody
out there was actually subclassing our GObjects.
In libnm 1.34 (commit e46d484fae ('libnm: hide NMSetting types from
public headers')) we moved the structs from headers to internal.
This would have caused a compiler error if anybody was using those
struct definitions. However, we still didn't change the ABI/layout so
that we didn't break users who relied on it (for whatever reason).
It doesn't seem there were any affected user. We waited long enough.
Change internal ABI.
No longer use g_type_class_add_private(). Instead, embed the private
structs directly (_NM_GET_PRIVATE()) or indirectly
(_NM_GET_PRIVATE_PTR()) in the object.
The main benefit is for debugging in the debugger, where we can now
easily find the private data. Previously that was so cumbersome to be
effectively impossible.
It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE()
literally resolves to "&self->_priv" (plus static asserts and
nm_assert() for type checking).
_NM_GET_PRIVATE() also propagates constness and requires that the
argument is a compatible pointer type (at compile time).
Note that g_type_class_add_private() is also deprecated in glib 2.58 and
replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also,
G_ADD_PRIVATE() is a worse solution as it supports a usecase that we
don't care for (public structs in headers). _NM_GET_PRIVATE() is still
faster, works with older glib and most importantly: is better for
debugging as you can find the private data from an object pointer.
For NMSettingIPConfig this is rather awkward, because all direct
properties require a common "klass->private_offset". This was however
the case before this change. Nothing new here. And if you ever touch
this and do something wrong, many unit tests will fail. It's almost
impossible to get wrong, albeit it can be confusing to understand.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
The default behavior is not to rename profiles. I guess, that makes
sense, as renaming a file when changing the "connection.id" could break
users who rely on the name.
My use case is the following. When I connect a Wi-Fi hotspot I use
`nmcli device wifi connect $SSID`, which -- as expected -- persists the
profile to "/etc/NetworkManager/system-connections/$SSID.nmconnection".
Later, I always update the profile's name to "w_$SSID" so I can see on
the name that this is wireless profile. I also want the filename to
reflect that change of name.
Add a configuration option for that. All the infrastructure
("force_rename" parameter) already exists.
The "connection.stable-id" supports placeholders like "${CONNECTION}" or
"${DEVICE}".
The stable-id can also be specified in global connection defaults in
NetworkManager.conf, by leaving it unset in the profile. Global
connection defaults always follow the pattern, that they correspond to a
per-profile property, and only when the per-profile value indicates a
special default/unset value, the global connection default is consulted.
Finally, if the global connection default is also not configured in
NetworkManager.conf, a built-in default is used (which may not be
constant either, for example ipv6.ip6-privacy's built-in default depends
on a sysctl value).
In any case, every possible configuration that can be achieved should be
configurable both per-profile and via global connection default. That
was not given for the stable-id, because the built-in default generated
an ID in a way that could not be explicitly expressed otherwise.
So you could not:
- explicitly set the per-profile value to the built-in default, to avoid
that the global-connection-default overwrites it.
- explicitly set the global-connection-default to the built-in default,
to avoid that a lower priority [connection*] section overwrites the
stable-id again.
Fix that inconsistency to make it possible to explicitly set the
built-in default.
Change behavior for literally "default${CONNECTION}" and make it behave
as the built-in default. Also document that the built-in default has that
value.
It's unlikely that this breaks an existing configuration, but of course,
if any user configured "connection.stable-id=default${CONNECTION}", then
the behavior changes for them.
Support managing the loopback interface through NM as the users want to
set the proper mtu for loopback interface when forwarding the packets.
Additionally, the IP addresses, DNS, route and routing rules are also
allowed to configure for the loopback connection profiles.
https://bugzilla.redhat.com/show_bug.cgi?id=2060905
