This reverts commit bb0a31e6.

This was pushed by accident.

If the ovs interface goes away, the ifindex gets zeroed out and l3cfg is
cleaned. We can't follow up with IP configuration. Bad things happen if
we try to:

  #0  0x00007f769734c895 in _g_log_abort (breakpoint=1) at gmessages.c:580
  #1  0x00007f769734db98 in g_logv (log_domain=0x55b2472d8840 "nm",
        log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>,
        args=args@entry=0x7fff4041b9d0) at gmessages.c:1391
  #2  0x00007f769734dd63 in g_log (log_domain=log_domain@entry=0x55b2472d8840 "nm",
        log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
        format=format@entry=0x7f769739a620 "%s: assertion '%s' failed") at gmessages.c:1432
  #3  0x00007f769734e59d in g_return_if_fail_warning
      (log_domain=log_domain@entry=0x55b2472d8840 "nm",
        pretty_function=pretty_function@entry=0x55b2472d5fe0 <__func__.39677> "nm_lndp_ndisc_new",
        expression=expression@entry=0x55b2472d5fa3 "NM_IS_L3CFG(config->l3cfg)")
        at gmessages.c:2809
  #4  0x000055b2471ce3fa in nm_lndp_ndisc_new (config=config@entry=0x7fff4041bb30)
        at src/core/ndisc/nm-lndp-ndisc.c:680
  #5  0x000055b247123b32 in _dev_ipac6_start (self=self@entry=0x55b248078360 [NMDeviceOvsInterface])
        at src/core/devices/nm-device.c:11287
  #6  0x000055b2471232f8 in _dev_ipac6_start_continue (self=0x55b248078360 [NMDeviceOvsInterface])
        at src/core/devices/nm-device.c:11338
  #7  0x000055b2471232f8 in _dev_ipll6_set_llstate (self=0x55b248078360 [NMDeviceOvsInterface],
        llstate=<optimized out>, lladdr=<optimized out>) at src/core/devices/nm-device.c:10541
  #8  0x000055b2471c9e8b in _emit_changed_on_idle_cb (user_data=user_data@entry=0x55b24807bdd0)
        at src/core/nm-l3-ipv6ll.c:221
  #9  0x00007f769734327b in g_idle_dispatch (source=0x55b248119200,
        callback=0x55b2471c9ce0 <_emit_changed_on_idle_cb>,
        user_data=0x55b24807bdd0) at gmain.c:5579
  #10 0x00007f769734695d in g_main_dispatch (context=0x55b247f56bc0) at gmain.c:3193
  #11 0x00007f769734695d in g_main_context_dispatch (context=context@entry=0x55b247f56bc0)
        at gmain.c:3873
  #12 0x00007f7697346d18 in g_main_context_iterate (context=0x55b247f56bc0,
        block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3946
  #13 0x00007f7697347042 in g_main_loop_run (loop=0x55b247f320f0) at gmain.c:4142
  #14 0x000055b246f26b64 in main (argc=<optimized out>,
        argv=<optimized out>) at src/core/main.c:511

https://bugzilla.redhat.com/show_bug.cgi?id=2012934
!1044

Fixes-test: @ovs_cloned_mac_set_on_iface

If the ovs interface goes away, the ifindex gets zeroed out and l3cfg is
cleaned. Avoid starting ac6 in that case -- add checks similar to what
we do for ll6.

Bad things happen otherwise:

  #0  0x00007f769734c895 in _g_log_abort (breakpoint=1) at gmessages.c:580
  #1  0x00007f769734db98 in g_logv (log_domain=0x55b2472d8840 "nm",
        log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>,
        args=args@entry=0x7fff4041b9d0) at gmessages.c:1391
  #2  0x00007f769734dd63 in g_log (log_domain=log_domain@entry=0x55b2472d8840 "nm",
        log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
        format=format@entry=0x7f769739a620 "%s: assertion '%s' failed") at gmessages.c:1432
  #3  0x00007f769734e59d in g_return_if_fail_warning
      (log_domain=log_domain@entry=0x55b2472d8840 "nm",
        pretty_function=pretty_function@entry=0x55b2472d5fe0 <__func__.39677> "nm_lndp_ndisc_new",
        expression=expression@entry=0x55b2472d5fa3 "NM_IS_L3CFG(config->l3cfg)")
        at gmessages.c:2809
  #4  0x000055b2471ce3fa in nm_lndp_ndisc_new (config=config@entry=0x7fff4041bb30)
        at src/core/ndisc/nm-lndp-ndisc.c:680
  #5  0x000055b247123b32 in _dev_ipac6_start (self=self@entry=0x55b248078360 [NMDeviceOvsInterface])
        at src/core/devices/nm-device.c:11287
  #6  0x000055b2471232f8 in _dev_ipac6_start_continue (self=0x55b248078360 [NMDeviceOvsInterface])
        at src/core/devices/nm-device.c:11338
  #7  0x000055b2471232f8 in _dev_ipll6_set_llstate (self=0x55b248078360 [NMDeviceOvsInterface],
        llstate=<optimized out>, lladdr=<optimized out>) at src/core/devices/nm-device.c:10541
  #8  0x000055b2471c9e8b in _emit_changed_on_idle_cb (user_data=user_data@entry=0x55b24807bdd0)
        at src/core/nm-l3-ipv6ll.c:221
  #9  0x00007f769734327b in g_idle_dispatch (source=0x55b248119200,
        callback=0x55b2471c9ce0 <_emit_changed_on_idle_cb>,
        user_data=0x55b24807bdd0) at gmain.c:5579
  #10 0x00007f769734695d in g_main_dispatch (context=0x55b247f56bc0) at gmain.c:3193
  #11 0x00007f769734695d in g_main_context_dispatch (context=context@entry=0x55b247f56bc0)
        at gmain.c:3873
  #12 0x00007f7697346d18 in g_main_context_iterate (context=0x55b247f56bc0,
        block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3946
  #13 0x00007f7697347042 in g_main_loop_run (loop=0x55b247f320f0) at gmain.c:4142
  #14 0x000055b246f26b64 in main (argc=<optimized out>,
        argv=<optimized out>) at src/core/main.c:511

This is the style we have ever since. Spell it out. With the difference
that now single line statements may have braces.

Recently we were already sloppy about allowing curly braces for single line
statements. Maybe there was a point in that. Imagine you start with:

    if (condition)
        call(some, parameter);

Afterwards you change the code so that the line becomes too long and
clang-format wraps the line (requiring you to add braces):

    if (condition) {
        call(some,
             call_another_function(hey));
    }

The problem now is that this diff is larger than it would have been, if
you added curly braces from the start. Also, it means you have to go
back and forth to add/remove these braces, as clang-format reformats the
code.

Also, if you have if-else-if blocks, then mixing multi line statements
with single line statements is also cumbersome, because when something
needs to change, the diff is may be larger (and the change more
cumbersome).

So it might be convenient to just always add the braces, and the
documented style now allows for that.

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: 4154d961 ('bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data')

!1052

Ana Cabral authored Jan 05, 2022 and Ana Cabral committed Jan 10, 2022

https://bugzilla.redhat.com/show_bug.cgi?id=2001563

Ana Cabral authored Jan 07, 2022 and Ana Cabral committed Jan 10, 2022

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: ae415212 ('ovs/ovsdb: add support for setting dpdk devargs option')

!1057

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.

James Hilliard authored Dec 02, 2021 and Thomas Haller committed Jan 04, 2022

Distributions may want to change the default wifi.backend, if for
example they are building without wpa_supplicant support.

NetworkManager/NetworkManager#869

NetworkManager/NetworkManager!1040

Tomohiro Mayama authored Dec 19, 2021 and Thomas Haller committed Jan 03, 2022

Signed-off-by: Tomohiro Mayama <parly-gh@iris.mystia.org>

!1050

Sam Morris authored Dec 10, 2021 and Thomas Haller committed Jan 03, 2022

[thaller@redhat.com: update translation strings and regenerate
  expected output for nmcli tests]

!1046

Beniamino Galvani authored Dec 20, 2021 and Thomas Haller committed Jan 03, 2022

Properly print properties containing a GVariant (as those backed by
a gendata hashtable).

For example, before:

 ++ ethtool.ring-rx-mini      = ???

After:

 ++ ethtool.ring-rx-mini      = 0

https://bugzilla.redhat.com/show_bug.cgi?id=2034086

!1051

!1033

  $ 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: e5b46aa3 ('cli: use nmc_string_to_ternary() to parse ternary in _set_fcn_ethtool()')

core: don't reset assume state if the device is unmanaged by parent

!1048

Wen Liang authored Dec 14, 2021 and Wen Liang committed Dec 20, 2021

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 3c4450aa ('core: don't reset assume state too
early') did something similar for NM_UNMANAGED_PLATFORM_INIT flag only.

xiangnian authored Dec 09, 2021 and Beniamino Galvani committed Dec 10, 2021

!1043

Before the l3cfg rework, the ip-iface property was exported only for
interfaces with an ifindex, and only in some device states.

Restore the old behavior since it is part of the API. For example,
firewalld uses the property to tell which interfaces have a ifindex.

Fixes: 58287cbc ('core: rework IP configuration in NetworkManager using layer 3 configuration')

https://bugzilla.redhat.com/show_bug.cgi?id=2026024
!1042

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=1861527
!1038

Only create a default connection with rd.neednet if we're starting with
a totally blank slate. Otherwise it could be that the user already
included configuration in the initrd and merely wants us to activate it.

!999

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: 14962cb4 ('merge: branch 'next''):

https://bugzilla.redhat.com/show_bug.cgi?id=2013921
!1011

!1036

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
```

Nacho Barrientos authored Nov 29, 2021 and Beniamino Galvani committed Nov 30, 2021

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
https://github.com/NetworkManager/NetworkManager/commit/51f93e00a23fbd09f5ad96da6290bf4ca737d46a).

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/21558

https://bugzilla.redhat.com/show_bug.cgi?id=2027267
#863

流浪猫 authored Nov 09, 2021 and Lubomir Rintel committed Nov 30, 2021

!1021