This reverts commit 389575a6.

When the command line contains BOOTIF and there is another ip=
argument specifying an interface name, we can follow 2 approaches:

 a) BOOTIF creates a new distinct connection with DHCP
    (the behaviour before the commit)

 b) the connection generated for ip= will be also be bound to the
    BOOTIF MAC (the behavior introduced by the commit)

Restore a) because we can't be sure that the MAC address refers to the
same interface. In that case it's preferable to generate a different
connection.

https://bugzilla.redhat.com/show_bug.cgi?id=1915493#c35

NetworkManager/NetworkManager#690

Fixes: 54976f23 ('build: move "clients/common/" to "src/libnmc-{base,setting}/"')

Fixes: 39225258 ('build: move "shared/systemd" to "src/libnm-systemd-shared"')

NetworkManager/NetworkManager#690

It's not entirely clear how to treat %NULL.
Clearly "match.interface-name=eth0" should not
match with an interface %NULL. But what about
"match.interface-name=!eth0"? It's now implemented
that negative matches still succeed against %NULL.
What about "match.interface-name=*"? That probably
should also match with %NULL. So we treat %NULL really
like "".

Against commit 11cd4434 ('iwd: Don't call IWD methods when device
unmanaged'), we got this backtrace:

    #0  0x00007f1c164069f1 in __strnlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62
    #1  0x00007f1c1637ac9e in __fnmatch (pattern=<optimized out>, string=<optimized out>, string@entry=0x0, flags=flags@entry=0) at fnmatch.c:379
            p = 0x0
            res = <optimized out>
            orig_pattern = <optimized out>
            n = <optimized out>
            wpattern = 0x7fff8d860730 L"pci-0000:03:00.0"
            ps = {__count = 0, __value = {__wch = 0, __wchb = "\000\000\000"}}
            wpattern_malloc = 0x0
            wstring_malloc = 0x0
            wstring = <optimized out>
            alloca_used = 80
            __PRETTY_FUNCTION__ = "__fnmatch"
    #2  0x0000564484a978bf in nm_wildcard_match_check (str=0x0, patterns=<optimized out>, num_patterns=<optimized out>) at src/core/nm-core-utils.c:1959
            is_inverted = 0
            is_mandatory = 0
            match = <optimized out>
            p = 0x564486c43fa0 "pci-0000:03:00.0"
            has_optional = 0
            has_any_optional = 0
            i = <optimized out>
    #3  0x0000564484bf4797 in check_connection_compatible (self=<optimized out>, connection=<optimized out>, error=0x0) at src/core/devices/nm-device.c:7499
            patterns = <optimized out>
            device_driver = 0x564486c76bd0 "veth"
            num_patterns = 1
            priv = 0x564486cbe0b0
            __func__ = "check_connection_compatible"
            device_iface = <optimized out>
            local = 0x564486c99a60
            conn_iface = 0x0
            klass = <optimized out>
            s_match = 0x564486c63df0 [NMSettingMatch]
    #4  0x0000564484c38491 in check_connection_compatible (device=0x564486cbe590 [NMDeviceVeth], connection=0x564486c6b160, error=0x0) at src/core/devices/nm-device-ethernet.c:348
            self = 0x564486cbe590 [NMDeviceVeth]
            s_wired = <optimized out>

Fixes: 3ced486f ('libnm/match: extend syntax for match patterns with '|', '&', '!' and '\\'')

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

Let's shortcut the test by consistently checking whether num_patterns
is positive before matching.

It's more about having a consistent form of the "if" checks, than
anything else.

Wen Liang authored Mar 21, 2021 and Beniamino Galvani committed Mar 24, 2021

Signed-off-by: Wen Liang <liangwen12year@gmail.com>

NetworkManager/NetworkManager!792

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

NetworkManager/NetworkManager!790

When adding an IPv4 address, kernel automatically adds a local route.
This is done by fib_add_ifaddr(). Note that if the address is
IFA_F_SECONDARY, then the "src" is the primary address. That means, with

  nmcli connection add con-name t type ethernet ifname t autoconnect no \
     ipv4.method manual ipv6.method disabled \
     ipv4.addresses '192.168.77.10/24, 192.168.77.11/24'

we get two routes:

  "local 192.168.77.10 dev t table local proto kernel scope host src 192.168.77.10"
  "local 192.168.77.11 dev t table local proto kernel scope host src 192.168.77.10"

Our code would only generate instead:

  "local 192.168.77.10 dev t table local proto kernel scope host src 192.168.77.10"
  "local 192.168.77.11 dev t table local proto kernel scope host src 192.168.77.11"

Afterwards, this artificial route will be leaked:

    #!/bin/bash

    set -vx

    nmcli connection delete t || :
    ip link delete t || :

    ip link add name t type veth peer t-veth

    nmcli connection add con-name t type ethernet ifname t autoconnect no ipv4.method manual ipv4.addresses '192.168.77.10/24, 192.168.77.11/24' ipv6.method disabled

    nmcli connection up t

    ip route show table all dev t | grep --color '^\|192.168.77.11'

    sleep 1

    nmcli device modify t -ipv4.addresses 192.168.77.11/24

    ip route show table all dev t | grep --color '^\|192.168.77.11'

    ip route show table all dev t | grep -q 192.168.77.11 && echo "the local route 192.168.77.11 is still there, because NM adds a local route with wrong pref-src"

It will also be leaked because in the example above ipv4.route-table is
unset, so we are not in full route sync mode and the local table is not
synced.

This was introduced by commit 3e5fc04d ('core: add dependent local
routes configured by kernel'), but it's unclear to me why we really need
this. Drop it again and effectively revert commit 3e5fc04d ('core:
add dependent local routes configured by kernel').

I think this "solution" is still bad. We need to improve our route sync
approach with L3Cfg rework. For now, it's probably good enough.

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

This effectively reverts commit cd89026c ('core: add dependent
multicast route configured by kernel for IPv6').

It's not clear to me why this was done or why it would be correct.

True, kernel automatically adds multicast route like

  multicast ff00::/8 dev $IFACE table local proto kernel metric 256 pref medium

But NetworkManager ignores all multicast routes for now. So the dependent
routes cannot contain multicast routes as they are not handled. Also,
the code added a unicast route, so I don't understand why the comment
is talking about multicast.

This seems just wrong. Drop it.

When we deactivate a device, we flush all IP addresses and
routes. Thus, have yet another sync mode for that. It will sync more
than "ALL".

NetworkManager/NetworkManager!695

Andrew Zaborowski authored Nov 27, 2020 and Thomas Haller committed Mar 23, 2021

Watch for NMSettingConnection changes and creation signals and convert
them to IWD format and write them to the configured IWD profile storage
directory.  The logic is off by default and gets enabled when the new
iwd-config-path setting in nm.conf's [main] group is set to a path to
an existing directory.

The idea here is that when a user edits an NM connection profile, the
change is immediately mirrored in IWD since IWD watches its
configuration directory using inotify.  This way NM clients can be used
to edit 802.1x settings, the PSK passphrase or the SSID -- changes that
would previously not take effect with the IWD backend.

Some precautions are taken to not make connections owned by a user
available to other users, such connections are not converted at all.
In all other cases where a connection cannot be converted sufficiently
well to the IWD format, for various reasons, we also give up and not
mirror these connections.

Due to IWD limitations and design differences with NM this logic has
many problems where it may not do its task properly.  It's meant to work
on a best-effort and "better than nothing" basis, but it should be safe
in that it shouldn't delete users data or reveal secrets, etc.  The most
obvious limitation is that there can be multiple NM connections
referring to the same SSID+Security tuple and only one IWD profile can
exist because the filename is based on only the SSID+Security type.  We
already had one NM connection selected for each IWD KnownNetwork and
referenced by a pointer, so we ignore changes in NM connections other
than that selected one.

Andrew Zaborowski authored Nov 27, 2020 and Thomas Haller committed Mar 23, 2021

Add code that can take an NMConnection and convert it to the IWD
network config file format so as to be able to mirror NM connection
profiles to IWD connection profiles and make basic editing IWD
profile possible from nm-connection-editor.  The focus here is on 802.1x
settings.

NetworkManager/NetworkManager!788

  In file included from ./src/libnm-glib-aux/nm-default-glib.h:11:0,
                   from ./src/libnm-glib-aux/nm-default-glib-i18n-lib.h:13,
                   from src/libnm-log-null/nm-logging-null.c:6:
  ./src/libnm-std-aux/nm-default-std.h:32:26: fatal error: config-extra.h: No such file or directory
   #include "config-extra.h"
                            ^
  compilation terminated.
  make[1]: *** [src/libnm-log-null/src_libnm_log_null_libnm_log_null_la-nm-logging-null.lo] Error 1

  ../examples/C/glib/vpn-import-libnm.c: In function main:
  ../examples/C/glib/vpn-import-libnm.c:72:1: error: control reaches end of non-void function [-Werror=return-type]
   }
   ^

Fixes: 905f9975 ('example: importing vpn with libnm')

Older gcc doesn't like this:

  ../src/libnm-core-impl/nm-setting-wired.c:132:49: error: controlling expression type 'const char *const [31]' not compatible with any generic association type
             && (nm_utils_strv_find_binary_search(valid_s390_opts,
                                                  ^~~~~~~~~~~~~~~
  ../src/libnm-glib-aux/nm-shared-utils.h:2033:60: note: expanded from macro 'nm_utils_strv_find_binary_search'
          const char *const *const _strv   = NM_CAST_STRV_CC(strv);     \
                                                             ^
  ../src/libnm-glib-aux/nm-macros-internal.h:706:21: note: expanded from macro 'NM_CAST_STRV_CC'
          (_Generic ((value), \
                      ^

Jagadeesh Kotra authored Mar 19, 2021 and Thomas Haller committed Mar 22, 2021

!789

The goal of this code is to detect python, but prefer python3 while
also allowing the user to override the path.

That did not work in all cases, due to what seems like a bug in
AM_PATH_PYTHON(). AM_PATH_PYTHON() is documented to ignore failure
if [action-if-not-found] is given. So one might assume that:

  AM_PATH_PYTHON([3], [], [PYTHON=])
  if test -z "$PYTHON"; then
    AM_PATH_PYTHON([], [], [PYTHON=python])
  fi

first tries to look for v3, and if that fails search for any python
interpreter. That did not work however with:

  $ ./configure PYTHON=/usr/bin/python2
  ...
  checking pkg-config is at least version 0.9.0... yes
  checking whether /usr/bin/python2 version is >= 3... no
  configure: error: Python interpreter is too old

because the first AM_PATH_PYTHON() is fatal.

Work around that.

Fixes: 54a1cfa9 ('build: prefer python3 over python2 in autotools's configure script')

NetworkManager/NetworkManager!787

Imaging you track a list of NMRefString instances. You could
directly expose them as strv array, but then you need a way
from the string back to the NMRefString instance.

That's easy to do. Add NM_REF_STRING_UPCAST() for that.

In the fast path, ref/unref is just a atomic increment/decrement of an
integer. Let's inline that.