We need to first free "priv->bzobjs", which then will unlink all bzobjs
from the lists. The assert needs to go after.
https://bugzilla.redhat.com/show_bug.cgi?id=2028427
Fixes: 4154d9618c ('bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data')
NMSettingOvsDpdk does not have a verify() implementation that would prevent
the devargs property from being NULL. We must thus anticipate and handle
a NULL value.
Fixes: ae4152120a ('ovs/ovsdb: add support for setting dpdk devargs option')
We get the hostname via D-Bus (from hostnamed) or read it from file.
In the latter case, it is not ensured that it's valid UTF-8.
Non-UTF-8 "strings" are bad, because we might try to expose them
on D-Bus, log them or other bad things.
Sanitize the string by using backslash escaping. Maybe we should
outright reject such binary nonsense, but it's not done here,
for no strong reasons.
We have at least static and transient hostnames. Let's be clear which
one we are talking about.
Note that also NM_SETTINGS_HOSTNAME gets renamed to
NM_SETTINGS_STATIC_HOSTNAME, because it seems clearer.
The only purpose of NM_SETTINGS_STATIC_HOSTNAME is to be the backing
property for the "Hostname" D-Bus property for the NMDBusObject glue.
So, while the new name makes more sense to me, it's now also
inconsistent with it's primary use (the D-Bus property). Still...
There are very few places left where we would accept tabs in a source
file. Warn about that, even if it might cause some false positives.
I think this line was commented out due to a mistake.
We avoid printing pointer values directly, instead we usually call
NM_HASH_OBFUSCATE_PTR(). This hashes the pointers with a random seed
so they are not directly visible.
That obviously makes it harder to debug. Add an environment variable
to disable that.
$ NM_OBFUSCATE_PTR=0 LIBNM_CLIENT_DEBUG=trace,stdout nmcli
Note that this flag is only honored in debug builds (WITH_MORE_ASSERTS>0).
The "Ignore-Backport" tag can be used to mark a commit that should not
be backported. Similar to the "cherry picked from" line, which indicates
that the patch was backported.
Anyway, this didn't work correctly, because we first pre-filter the
commits we search (as a performance optimization) by using `git-log` to
get a subset of the commits we want to investigate.
So if you had a commit with an "Ignore-Backport" tag, but without "cherry
picked from" line, then it wasn't found.
Fix that.
Older branches, like "nm-1-32" will always be formatted with a
different, older clang-format version. Luckily we also have on "nm-1-32"
branch the "nm-code-format-container.sh" script, so we can still
reformat the sources using the container.
However, as the name of the container was always "nm-code-format",
we would have to re-generate the container when we switch between
branches. As the container really only depends on the Fedora version
(as the clang-format version is tied to the corresponding Fedora
version), let's include the Fedora version in the name of the container.
$ nmcli connection modify dummy1 ethtool.feature-rx a
(process:3077356): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: 'a' is not valid; use 'on', 'off', or 'ignore'
Error: failed to modify ethtool.feature-rx: 'a' is not valid; use [true, yes, on], [false, no, off] or [unknown].
Fixes: e5b46aa38a ('cli: use nmc_string_to_ternary() to parse ternary in _set_fcn_ethtool()')
When the device gets realized, similar to the situation that the device
is unmanaged by platform-init, if the device is still unmanaged by
parent and we clear the assume state. Then, when the device becomes
managed, NM is not able to properly assume the device using the UUID.
Therefore, we should not clear the assume state if the device has only
the NM_UNMANAGED_PLATFORM_INIT or the NM_UNMANAGED_PARENT flag set
in the unmanaged flags.
The previous commit 3c4450aa4d ('core: don't reset assume state too
early') did something similar for NM_UNMANAGED_PLATFORM_INIT flag only.
Routing daemons can add a large amount of routes to the
system. Currently NM receives netlink notifications for all those
routes and exposes them on D-Bus. With many routes, the daemon becomes
increasingly slow and uses a lot of memory.
The rtm_protocol field of the route indicates the source of the
route. From /usr/include/linux/rtnetlink.h, the allowed values are:
#define RTPROT_UNSPEC 0
#define RTPROT_REDIRECT 1 /* Route installed by ICMP redirects;
not used by current IPv4 */
#define RTPROT_KERNEL 2 /* Route installed by kernel */
#define RTPROT_BOOT 3 /* Route installed during boot */
#define RTPROT_STATIC 4 /* Route installed by administrator */
/* Values of protocol >= RTPROT_STATIC are not interpreted by kernel;
they are just passed from user and back as is.
It will be used by hypothetical multiple routing daemons.
Note that protocol values should be standardized in order to
avoid conflicts.
*/
#define RTPROT_GATED 8 /* Apparently, GateD */
#define RTPROT_RA 9 /* RDISC/ND router advertisements */
#define RTPROT_MRT 10 /* Merit MRT */
#define RTPROT_ZEBRA 11 /* Zebra */
#define RTPROT_BIRD 12 /* BIRD */
#define RTPROT_DNROUTED 13 /* DECnet routing daemon */
#define RTPROT_XORP 14 /* XORP */
#define RTPROT_NTK 15 /* Netsukuku */
#define RTPROT_DHCP 16 /* DHCP client */
#define RTPROT_MROUTED 17 /* Multicast daemon */
#define RTPROT_KEEPALIVED 18 /* Keepalived daemon */
#define RTPROT_BABEL 42 /* Babel daemon */
#define RTPROT_OPENR 99 /* Open Routing (Open/R) Routes */
#define RTPROT_BGP 186 /* BGP Routes */
#define RTPROT_ISIS 187 /* ISIS Routes */
#define RTPROT_OSPF 188 /* OSPF Routes */
#define RTPROT_RIP 189 /* RIP Routes */
#define RTPROT_EIGRP 192 /* EIGRP Routes */
Since NM uses only values <= RTPROT_STATIC, plus RTPROT_RA and
RTPROT_DHCP, add a BPF filter to the netlink socket to discard
notifications for other route types.
https://bugzilla.redhat.com/show_bug.cgi?id=1861527https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1038
This bumps L3_CONFIG_DATA_TYPE_MANUALIP to be the most important address
source; which is what had been the case before NetworkManager/next and
is presumably what the user expects.
It also comes into play for iBFT-booted machines, where iBFT contains a
permanent address (no lifetime data), while DHCP might lease out the
same one. In that case, expiry of the latter could potentially disrupt
connectivity to a vital storage volume.
Fixes: 14962cb414 ('merge: branch 'next''):
https://bugzilla.redhat.com/show_bug.cgi?id=2013921https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1011
When using the "remove" command on nmcli edit mode it will reset the
value to the default when no property value is specified. If the
property value is specified it will remove that specific property.
Example:
```
nmcli> set ethernet.wake-on-lan phy
nmcli> print ethernet.wake-on-lan
802-3-ethernet.wake-on-lan: phy, default
nmcli> remove ethernet.wake-on-lan default
nmcli> print ethernet.wake-on-lan
802-3-ethernet.wake-on-lan: phy
nmcli> remove ethernet.wake-on-lan
nmcli> print ethernet.wake-on-lan
802-3-ethernet.wake-on-lan: default
```
This patch introduces "add" command to nmcli edit mode. When using "add"
it will append the value to the ones already set. This is doing the same
thing than the "set" command does right now.
Example:
```
nmcli> add ipv4.addresses 192.168.1.1/24
```
I've seen this in `NetworkManager-1.34.0-0.3.el8.x86_64` (latest in CentOS
Stream 8 at the time of writing this message) which does not use the latest
Systemd but probably the code base is the same (see
51f93e00a2).
Before the patch:
```
libsystemd: eth0: DHCPv6 client: T1 expires in 34y 3w 6d 45min 31s
libsystemd: eth0: DHCPv6 client: T2 expires in 54y 5month 3w 3d 23h 20min 35s
```
After the patch:
```
libsystemd: eth0: DHCPv6 client: T1 expires in 3d 7h 58min 3s
libsystemd: eth0: DHCPv6 client: T2 expires in 5d 2h 26min 50s
```
same box (x86_64 system) and same DHCPv6 server.
This regression has likely been introduced by 8a8955507af363c31297bbc5df79852db4ad39d6.
See-also: https://github.com/systemd/systemd/pull/21558https://bugzilla.redhat.com/show_bug.cgi?id=2027267https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/863
Fix the following assertion failure:
src/core/nm-l3cfg.c:2636:_l3_acd_data_state_change: assertion failed: (!acd_data->nacd_probe)
When AcdData enters state NM_L3_ACD_ADDR_STATE_READY, the duplicate
address detection procedure completed successfully but the address is
not configured yet on the interface. In the READY state we don't clear
the probe because the same probe can be reused also for defending the
address. Change the assertion.
https://bugzilla.redhat.com/show_bug.cgi?id=2026288https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1035
We use clang-format for automatic formatting of our source files.
Since clang-format is actively maintained software, the actual
formatting depends on the used version of clang-format. That is
unfortunate and painful, but really unavoidable unless clang-format
would be strictly bug-compatible.
So the version that we must use is from the current Fedora release, which
is also tested by our gitlab-ci. Previously, we were using Fedora 34 with
clang-tools-extra-12.0.1-1.fc34.x86_64.
As Fedora 35 comes along, we need to update our formatting as Fedora 35
comes with version "13.0.0~rc1-1.fc35".
An alternative would be to freeze on version 12, but that has different
problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it
would be cumbersome for our developers which are on Fedora 35 to use a
clang that they cannot easily install).
The (differently painful) solution is to reformat from time to time, as we
switch to a new Fedora (and thus clang) version.
Usually we would expect that such a reformatting brings minor changes.
But this time, the changes are huge. That is mentioned in the release
notes [1] as
Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353)
[1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
When using OVS link aggregation ports, NetworkManager ovsdb is removing
the ports when cleaning it up. If that happens, it should deactivate the
device even if it does not have controller or the state is not
assume/external.
An interface that is port of the OVS bonding can be activated before the
ovsdb clean up, if it is not deactivated then NetworkManager will finish
with a wrong configuration. The 'ovsdb_device_removed()' is already
checking that the device is "ovs-interface" with subtype "system".
