1. 20 Jan, 2022 3 commits
    • Beniamino Galvani's avatar
      core: update hostname once at startup · 501f9b1c
      Beniamino Galvani authored
      NMPolicy stores the last hostname set in priv->cur_hostname and checks
      if it changed before notifying the DNS manager.
      
      _set_hostname() should be called one time early during startup so that
      the priv->cur_hostname gets initialized without triggering a DNS
      update.
      501f9b1c
    • Beniamino Galvani's avatar
      core: update DNS only when something relevant changes · bdf6f4d1
      Beniamino Galvani authored
      The DNS configuration needs to be updated only when relevant changes
      happen it the l3cd: either changes in DNS information or in routes
      (since routes are used to create the reverse DNS entries, and the
      default route influences DNS priorities).
      bdf6f4d1
    • Beniamino Galvani's avatar
      core: defer DNS updates until the device enters the SECONDARIES state · 8116289b
      Beniamino Galvani authored
      I see a significant performance increase with many parallel
      activations if DNS updates are deferred to the SECONDARIES state.
      
      Since there is no guarantee that device_l3cd_changed() is called again
      when the device becomes ACTIVATED, we need also to change
      device_state_changed().
      8116289b
  2. 10 Jan, 2022 1 commit
    • Thomas Haller's avatar
      core: rename related things explicitly to "static-hostname" · a3526474
      Thomas Haller authored
      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...
      a3526474
  3. 29 Nov, 2021 1 commit
    • Thomas Haller's avatar
      format: reformat source tree with clang-format 13.0 · 615221a9
      Thomas Haller authored and Beniamino Galvani's avatar Beniamino Galvani committed
      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
      615221a9
  4. 18 Nov, 2021 3 commits
    • Beniamino Galvani's avatar
      core: avoid stale entries in the DNS manager · b86388be
      Beniamino Galvani authored
      When a virtual interface is removed externally, the device is
      unrealized and the ifindex is cleared; this also detaches the existing
      l3cfg from the device. At this point the l3cd entry for the device
      lingers forever in the DNS manager.
      
      Emit a last L3CD_CHANGED so that the old entry gets removed.
      
      Fixes-test: @disconnect_from_pppoe
      b86388be
    • Beniamino Galvani's avatar
    • Thomas Haller's avatar
      core: rework IP configuration in NetworkManager using layer 3 configuration · 58287cbc
      Thomas Haller authored and Beniamino Galvani's avatar Beniamino Galvani committed
      
      
      Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3
      manager for the IP configuration of an interface. Use NML3ConfigData as
      pieces of configuration that the various components collect and
      configure. NMDevice is managing most of the IP configuration at a higher
      level, that is, it starts DHCP and other IP methods. Rework the state
      handling there.
      
      This is a huge rework of how NetworkManager daemon handles IP
      configuration. Some fallout is to be expected.
      
      It appears the patch deletes many lines of code. That is not accurate, because
      you also have to count the files `src/core/nm-l3*`, which were unused previously.
      
      Co-authored-by: Beniamino Galvani's avatarBeniamino Galvani <bgalvani@redhat.com>
      58287cbc
  5. 02 Nov, 2021 1 commit
  6. 11 Aug, 2021 1 commit
  7. 06 Aug, 2021 1 commit
  8. 05 Aug, 2021 2 commits
  9. 21 Jun, 2021 1 commit
    • Beniamino Galvani's avatar
      policy: prefer IPv4 to determine the hostname · 637a45e2
      Beniamino Galvani authored
      When determining the hostname, it is preferable to evaluate devices in
      a predictable order to avoid that the hostname changes between
      different boots.
      
      The current order is based first on hostname priority, then on the
      presence of a best default route, and then on activation order.
      
      The activation order is not a very strong condition, as it is
      basically useless for devices that are autoactivated at boot.
      
      As we already prefer IPv4 over IPv6 within the same connection, also
      prefer it when 2 connections have the same priority and the same
      default route status, to achieve better predictability.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1970335
      !895
      637a45e2
  10. 06 May, 2021 2 commits
  11. 23 Apr, 2021 1 commit
    • Andrew Zaborowski's avatar
      settings: Drop nm_settings_connection_clear_secrets · d1566d7b
      Andrew Zaborowski authored and Thomas Haller's avatar Thomas Haller committed
      All usages of nm_settings_connection_clear_secrets() outside of the
      NMSettingsConnection implementation were setting the
      clear_cached_system_secrets parameter to FALSE which meant that the
      operation was a no-op since the system-secrets cache kept a copy of the
      secrets being cleared and any access to the SettingsConnection through
      the D-Bus API or the class methods would behave the same as without the
      call, with the exception of directly reading the settings from the
      result of nm_settings_connection_get_connection().  The calls would
      still generate D-Bus and gobject signals however, which were redundant.
      
      Drop the method and its calls from the rest of NM code as not needed and
      potentially confusing.  The comments preceding these calls implied that
      they were needed so that the next activation attempt would be forced to
      use nm_settings_connection_get_secrets() but this was the case probably
      only before the applied connection concept was introduced.
      
      Also drop two nm_active_connection_clear_secrets() uses in
      NMVpnConnection, right before the teardown of the active connection,
      that could only possibly have any effect if they affected the
      NMSettingsConnection, but as mentioned earlier the
      nm_settings_connection_clear_secrets() use inside
      nm_active_connection_clear_secrets() didn't do anything and is now
      removed.
      
      The one internal use of nm_active_connection_clear_secrets() in the
      D-Bus ClearSecrets() implementation is inlined.
      d1566d7b
  12. 05 Mar, 2021 1 commit
  13. 18 Feb, 2021 1 commit
    • Thomas Haller's avatar
      build: move "libnm-core/" to "src/" and split it · fdf9614b
      Thomas Haller authored
      "libnm-core/" is rather complicated. It provides a static library that
      is linked into libnm.so and NetworkManager. It also contains public
      headers (like "nm-setting.h") which are part of public libnm API.
      
      Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which
      only rely on public API of libnm-core, but are themself static
      libraries that can be used by anybody who uses libnm-core. And
      "libnm-core/nm-libnm-core-intern" is used by libnm-core itself.
      
      Move "libnm-core/" to "src/". But also split it in different
      directories so that they have a clearer purpose.
      
      The goal is to have a flat directory hierarchy. The "src/libnm-core*/"
      directories correspond to the different modules (static libraries and set
      of headers that we have). We have different kinds of such modules because
      of how we combine various code together. The directory layout now reflects
      this.
      fdf9614b
  14. 09 Feb, 2021 1 commit
  15. 08 Feb, 2021 1 commit
  16. 04 Feb, 2021 1 commit
    • Thomas Haller's avatar
      all: move "src/" directory to "src/core/" · ac1a9e03
      Thomas Haller authored
      Currently "src/" mostly contains the source code of the daemon.
      I say mostly, because that is not true, there are also the device,
      settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp
      helper, and probably more.
      
      Also we have source code under libnm-core/, libnm/, clients/, and
      shared/ directories. That is all confusing.
      
      We should have one "src" directory, that contains subdirectories. Those
      subdirectories should contain individual parts (libraries or
      applications), that possibly have dependencies on other subdirectories.
      There should be a flat hierarchy of directories under src/, which
      contains individual modules.
      
      As the name "src/" is already taken, that prevents any sensible
      restructuring of the code.
      
      As a first step, move "src/" to "src/core/". This gives space to
      reorganize the code better by moving individual components into "src/".
      
      For inspiration, look at systemd's "src/" directory.
      
      https://gitlab.freedesktop.org/NetworkManager/NetworkM...
      ac1a9e03
  17. 27 Jan, 2021 1 commit
    • Beniamino Galvani's avatar
      core: unblock OVS interfaces when the ovsdb is ready · e2b44175
      Beniamino Galvani authored
      OVS system interfaces can start to connect even before the ovsdb is
      ready. However, the connection attempt is doomed to fail and the
      NMSettingsConnection gets blocked with reason FAILED.
      
      Unblock them once the ovsdb is ready.
      
      Ideally, NMPolicy should subscribe to the NMOvsdb::ready signal,
      however NMOvsdb is in a plugin, so it's easier if NMOvsdb directly
      calls a function of the core.
      e2b44175
  18. 18 Jan, 2021 2 commits
    • Beniamino Galvani's avatar
      all: change default value of hostname.only-from-default to false · 92c494f2
      Beniamino Galvani authored
      Currently, is retrieved by default only from the device with the
      default route. This is done so that in presence of multiple
      connections the choice is deterministic.
      
      However, this limitation seems confusing for users, that expect to get
      an hostname even for non-default devices. Change the default and allow
      any device to obtain the hostname.
      
      Note that when there is a default route, NM still prefers that device
      and so the behavior doesn't change.
      
      The only change in behavior is that when there is no default route and
      the machine doesn't have a static hostname, NM will try to get
      hostname from DHCP or reverse DNS.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1766944
      92c494f2
    • Beniamino Galvani's avatar
      policy: prefer device with default route to determine the hostname · af55a86a
      Beniamino Galvani authored
      In case two devices have the same hostname-priority, prefer the one
      with the best default route. In this way, even if
      hostname.only-from-default is set to FALSE globally, the behavior is
      similar to the past when there is a device with the default route.
      
      Previously, NMPolicy considered only the hostname-priority and the
      activation order to build the DeviceHostnameInfo list. Now it has to
      consider also the presence of the default route, which depends on the
      address family. Therefore, now there is a DeviceHostnameInfo for each
      [device,address_family] combination.
      af55a86a
  19. 08 Jan, 2021 1 commit
    • Thomas Haller's avatar
      core: avoid "-Wmaybe-uninitialized" warning in update_system_hostname() with LTO · f8026717
      Thomas Haller authored
      When building without more-assertions and LTO, the compiler might think
      that "wait" is uninitialized. Avoid the warning.
      
      Initializing a variable is not a great solution either, because
      potentially it could hide an actual bug. But it still seems to be
      best.
      
          src/nm-policy.c: In function update_system_hostname:
          src/nm-policy.c:909: warning: wait may be used uninitialized in this function [-Wmaybe-uninitialized]
            909 |                     if (wait) {
                |
          src/nm-policy.c:901: note: wait was declared here
            901 |                     gboolean    wait;
                |
      f8026717
  20. 05 Jan, 2021 1 commit
    • Thomas Haller's avatar
      all: update deprecated SPDX license identifiers · 977ea352
      Thomas Haller authored
      These SPDX license identifiers are deprecated ([1]). Update them.
      
      [1] https://spdx.org/licenses/
      
        sed \
           -e '1 s%^/\* SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+ \*/$%/* SPDX-License-Identifier: \1-or-later */%' \
           -e '1,2 s%^\(--\|#\|//\) SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+$%\1 SPDX-License-Identifier: \2-or-later%' \
           -i \
           $(git grep -l SPDX-License-Identifier -- \
               ':(exclude)shared/c-*/' \
               ':(exclude)shared/n-*/' \
               ':(exclude)shared/systemd/src' \
               ':(exclude)src/systemd/src')
      977ea352
  21. 18 Dec, 2020 1 commit
  22. 04 Dec, 2020 1 commit
  23. 02 Dec, 2020 1 commit
  24. 19 Nov, 2020 2 commits
  25. 17 Nov, 2020 2 commits
    • Thomas Haller's avatar
      dns: don't apply DNS configuration for external connections · ee4e679b
      Thomas Haller authored
      External connections are devices that are configured outside of
      NetworkManager. Such devices should be mostly ignored and not
      be interfered with.
      
      Note that we tend to create external connection profiles for
      such devices. That happens for example if you use wg-quick to
      manage a WireGuard interface outside of NetworkManager. But it
      really happens for any interface.
      
      This generated profile has no DNS configuration. Unless we use
      the systemd-resolved backend, they thus don't contribute to the DNS
      settings (which is fine).
      
      However, with systemd-resolved, NetworkManager would also reset
      the DNS configuration of those external interfaces. That is clearly
      wrong. NetworkManager should only care about the interfaces that it
      actively manages and leave others alone.
      
      How to reproduce: use systemd-resolved and configure an interface outside
      of NetworkManager. Note that `nmcli device` shows the state as
      "connected (externally)". Note that `resolvectl` shows the DNS configuration
      on that external interface. Do something in NetworkManager to trigger
      a DNS update (e.g. SIGHUB or reactivate a profile). Note in `resolvectl`
      that the external interface's DNS configuration was wiped.
      
      #563 (comment 673283)
      (cherry picked from commit 39566590)
      ee4e679b
    • Thomas Haller's avatar
      dns: don't apply DNS configuration for external connections · 39566590
      Thomas Haller authored
      External connections are devices that are configured outside of
      NetworkManager. Such devices should be mostly ignored and not
      be interfered with.
      
      Note that we tend to create external connection profiles for
      such devices. That happens for example if you use wg-quick to
      manage a WireGuard interface outside of NetworkManager. But it
      really happens for any interface.
      
      This generated profile has no DNS configuration. Unless we use
      the systemd-resolved backend, they thus don't contribute to the DNS
      settings (which is fine).
      
      However, with systemd-resolved, NetworkManager would also reset
      the DNS configuration of those external interfaces. That is clearly
      wrong. NetworkManager should only care about the interfaces that it
      actively manages and leave others alone.
      
      How to reproduce: use systemd-resolved and configure an interface outside
      of NetworkManager. Note that `nmcli device` shows the state as
      "connected (externally)". Note that `resolvectl` shows the DNS configuration
      on that external interface. Do something in NetworkManager to trigger
      a DNS update (e.g. SIGHUB or reactivate a profile). Note in `resolvectl`
      that the external interface's DNS configuration was wiped.
      
      #563 (comment 673283)
      39566590
  26. 16 Nov, 2020 2 commits
    • Beniamino Galvani's avatar
      policy: use the hostname setting · 09c83871
      Beniamino Galvani authored
      Rework update_system_hostname() to use the new properties from the
      hostname setting.
      
      In the default configuration where all the 3 boolean properties
      hostname.{from-dhcp,from-dns,only-from-default} are true, the behavior
      is the same as before.
      09c83871
    • Beniamino Galvani's avatar
      core: reverse the order of active connections in the manager · dc6ec6ce
      Beniamino Galvani authored
      When a new active connection is created, it gets added at the
      beginning of manager's list. This means that the list contains most
      recently activated connections first. Since the list is doubly-linked,
      it is possible to efficiently iterate in both directions, so the order
      of the list is mostly a matter of convention.
      
      I think it is preferable to have oldest active connections at the
      beginning of the list; let's reverse the order.
      
      In most places where the list is iterated, the order doesn't
      matter. Where it does, use the *_prev() variant to maintain the old
      iteration order.
      dc6ec6ce
  27. 29 Sep, 2020 2 commits
  28. 28 Sep, 2020 2 commits