1. 16 Jul, 2019 1 commit
    • Thomas Haller's avatar
      settings: rework tracking settings connections and settings plugins · d35d3c46
      Thomas Haller authored
      Completely rework how settings plugin handle connections and how
      NMSettings tracks the list of connections.
      Previously, settings plugins would return objects of (a subtype of) type
      NMSettingsConnection. The NMSettingsConnection was tightly coupled with
      the settings plugin. That has a lot of downsides.
      Change that. When changing this basic relation how settings connections
      are tracked, everything falls appart. That's why this is a huge change.
      Also, since I have to largely rewrite the settings plugins, I also
      added support for multiple keyfile directories, handle in-memory
      connections only by keyfile plugin and (partly) use copy-on-write NMConnection
      instances. I don't want to spend effort rewriting large parts while
      preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh,
      I don't want to let it handle in-memory connections because that's not right
      If the settings plugins themself create subtypes of NMSettingsConnection
      instances, then a lot of knowledge about tracking connections moves
      to the plugins.
      Just try to follow the code what happend during nm_settings_add_connection().
      Note how the logic is spread out:
       - nm_settings_add_connection() calls plugin's add_connection()
       - add_connection() creates a NMSettingsConnection subtype
       - the plugin has to know that it's called during add-connection and
       - NMSettings calls claim_connection() which hocks up the new
         NMSettingsConnection instance and configures the instance
         (like calling nm_settings_connection_added()).
      This summary does not sound like a lot, but try to follow that code. The logic
      is all over the place.
      Instead, settings plugins should have a very simple API for adding, modifying,
      deleting, loading and reloading connections. All the plugin does is to return a
      NMSettingsStorage handle. The storage instance is a handle to identify a profile
      in storage (e.g. a particular file). The settings plugin is free to subtype
      NMSettingsStorage, but it's not necessary.
      There are no more events raised, and the settings plugin implements the small
      API in a straightforward manner.
      NMSettings now drives all of this. Even NMSettingsConnection has now
      very little concern about how it's tracked and delegates only to NMSettings.
      This should make settings plugins simpler. Currently settings plugins
      are so cumbersome to implement, that we avoid having them. It should not be
      like that and it should be easy, beneficial and lightweight to create a new
      settings plugin.
      Note also how the settings plugins no longer care about duplicate UUIDs.
      Duplicated UUIDs are a fact of life and NMSettings must handle them. No
      need to overly concern settings plugins with that.
      NMSettingsConnection is exposed directly on D-Bus (being a subtype of
      NMDBusObject) but it was also a GObject type provided by the settings
      plugin. Hence, it was not possible to migrate a profile from one plugin to
      However that would be useful when one profile does not support a
      connection type (like ifcfg-rh not supporting VPN). Currently such
      migration is not implemented except for migrating them to/from keyfile's
      run directory. The problem is that migrating profiles in general is
      complicated but in some cases it is important to do.
      For example checkpoint rollback should recreate the profile in the right
      settings plugin, not just add it to persistent storage. This is not yet
      properly implemented.
      Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved)
      profiles, while ifupdown plugin cannot handle them. That meant duplication of code
      and a ifupdown profile could not be modified or made unsaved.
      This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711).
      Also, NMSettings is aware of such profiles and treats them specially.
      In particular, NMSettings drives the migration between persistent and non-persistent
      Note that a settings plugins may create truly generated, in-memory profiles.
      The settings plugin is free to generate and persist the profiles in any way it
      wishes. But the concept of "unsaved" profiles is now something explicitly handled
      by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system
      too, to the /run directory. This is great for two reasons: first of all, all
      profiles from keyfile storage in fact have a backing file -- even the
      unsaved ones. It also means you can create "unsaved" profiles in /run
      and load them with `nmcli connection load`, meaning there is a file
      based API for creating unsaved profiles.
      The other advantage is that these profiles now survive restarting
      NetworkManager. It's paramount that restarting the daemon is as
      non-disruptive as possible. Persisting unsaved files to /run improves
      here significantly.
      In the past, NMSettingsConnection also implemented NMConnection interface.
      That was already changed a while ago and instead users call now
      nm_settings_connection_get_connection() to delegate to a
      NMSimpleConnection. What however still happened was that the NMConnection
      instance gets never swapped but instead the instance was modified with
      nm_connection_replace_settings_from_connection(), clear-secrets, etc.
      Change that and treat the NMConnection instance immutable. Instead of modifying
      it, reference/clone a new instance. This changes that previously when somebody
      wanted to keep a reference to an NMConnection, then the profile would be cloned.
      Now, it is supposed to be safe to reference the instance directly and everybody
      must ensure not to modify the instance. nmtst_connection_assert_unchanging()
      should help with that.
      The point is that the settings plugins may keep references to the
      NMConnection instance, and so does the NMSettingsConnection. We want
      to avoid cloning the instances as long as they are the same.
      Likewise, the device's applied connection can now also be referenced
      instead of cloning it. This is not yet done, and possibly there are
      further improvements possible.
      Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545,
      bgo #772414).
      It was always the case that multiple files could provide the same UUID
      (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in
      read-only storage in /usr/lib gets modified, then it gets actually stored in
      /etc (or /run, if the profile is unsaved).
      While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable.
  2. 05 Jun, 2019 4 commits
  3. 18 Apr, 2019 2 commits
  4. 21 Feb, 2019 2 commits
  5. 01 Feb, 2019 2 commits
  6. 27 Jan, 2019 2 commits
  7. 14 Jan, 2019 1 commit
    • Thomas Haller's avatar
      all: return output dictionary from "AddAndActivate2" · fbb038af
      Thomas Haller authored
      Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API.
      "AddAndActivate2" replaces "AddAndActivate" with more options.
      It also has a dictionary argument to be forward compatible so that we
      hopefully won't need an "AddAndActivate3". However, it lacked a similar
      output dictionary. Add it for future extensibility. I think this is
      really to workaround a shortcoming of D-Bus, which does provide strong
      typing and type information about its API, but does not allow to extend
      an existing API in a backward compatible manner. So we either resort to
      Method(), Method2(), Method3() variants, or a catch-all variant with a
      generic "a{sv}" input/output argument.
      In libnm, rename "nm_client_add_and_activate_connection_options()" to
      "nm_client_add_and_activate_connection2()". I think libnm API should have
      an obvious correspondence with D-Bus API. Or stated differently, if
      "AddAndActivateOptions" would be a better name, then the D-Bus API should
      be renamed. We should prefer one name over the other, but regardless
      of which is preferred, the naming for D-Bus and libnm API should
      In this case, I do think that AddAndActivate2() is a better name than
      AddAndActivateOptions(). Hence I rename the libnm API.
      Also, unless necessary, let libnm still call "AddAndActivate" instead of
      "AddAndActivate2". Our backward compatibility works the way that libnm
      requires a server version at least as new as itself. As such, libnm
      theoretically could assume that server version is new enough to support
      "AddAndActivate2" and could always use the more powerful variant.
      However, we don't need to break compatibility intentionally and for
      little gain. Here, it's easy to let libnm also handle old server API, by
      continuing to use "AddAndActivate" for nm_client_add_and_activate_connection().
      Note that during package update, we don't restart the currently running
      NetworkManager instance. In such a scenario, it can easily happen that
      nmcli/libnm is newer than the server version. Let's try a bit harder
      to not break that.
      Changes as discussed in [1].
      [1] !37 (comment 79876)
  8. 20 Dec, 2018 1 commit
  9. 29 Nov, 2018 1 commit
    • Lubomir Rintel's avatar
      all: say Wi-Fi instead of "wifi" or "WiFi" · b385ad01
      Lubomir Rintel authored
      Correct the spelling across the *entire* tree, including translations,
      comments, etc. It's easier that way.
      Even the places where it's not exposed to the user, such as tests, so
      that we learn how is it spelled correctly.
  10. 28 Nov, 2018 1 commit
  11. 19 Nov, 2018 1 commit
    • Thomas Haller's avatar
      all: rename "bind" option for AddAndActivateConnection2 to "bind-activation" · 7420ae83
      Thomas Haller authored
      "bind" specifically binds the lifetime of the activation (NMActiveConnection).
      In combination with "persist=volatile", the lifetime of the NMSettingsConnection
      is indirectly bound to the NMActiveConnection. But still these concepts make sense
      In the future, it may make sense to also bind the lifetime of the NMSettingsConnection
      to the D-Bus client. Hence, rename the option to allow for the distinction.
      Also, belatedly fix libnm comment about "bind" only working with
      "persist" "volatile".
      Fixes: eb883e34
  12. 18 Nov, 2018 1 commit
    • Thomas Haller's avatar
      manager: allow add-and-activate option "bind" with non-volatile profiles · 6f28f4b6
      Thomas Haller authored
      For one, there was a bug here: we cannot "goto error" without setting
      the @Error variable.
      Anyway, restricting "bind" "dbus-client" only to profiles that are
      "persist" mode "volatile" seems wrong. The "bind" option as it is,
      limits the lifetime of the active-connection. This has no direct relation
      with the lifetime of the setting-connection. Indeed, if the
      settings-connection's lifetime is itself set to "volatile", then
      it will indeed go away with the active-connection. However, these
      two concepts are not strictly related.
      In the future, we might add an option to limite the lifetime of
      a settings-connection to a D-Bus client ("bind-setting"). Possibly
      we should thus rename "bind" to "bind-activation", to make the
      distinction clearer.
  13. 17 Nov, 2018 3 commits
    • Benjamin Berg's avatar
      core: Add option to AddAndActivateConnection2 to bind the lifetime · eb883e34
      Benjamin Berg authored
      This allows binding the lifetime of the created connection to the
      existance of the requesting dbus client. This feature is useful if one
      has a service specific connection (e.g. P2P wireless) which will not be
      useful without the specific service.
      This is simply a mechanism to ensure proper connection cleanup if the
      requesting service has a failure.
    • Benjamin Berg's avatar
      core: Add persist option to AddAndActivateConnection2 · 9cef6483
      Benjamin Berg authored
      This option allows setting the rules for how long the connection should
      be stored. Valid values are "disk" (the default), "memory" and
      "volatile". If "memory" or "volatile" is selected, the connection will
      not be saved to disk and with "volatile" it will be automatically
      removed when it is deactivated again.
    • Benjamin Berg's avatar
      core: Add an AddAndActivateConnection2 routine with options parameter · 43c19d75
      Benjamin Berg authored
      This adds a new routine to be able to handle an arbitrary set of further
      options for AddAndActivateConnection. Note that no options are accepted
      for now.
  14. 28 Sep, 2018 1 commit
    • Beniamino Galvani's avatar
      build: meson: fix generation of api docs · dcfddeef
      Beniamino Galvani authored
      We need to copy all introspection files to the same directory when
      building the documentation.
      Note that we only require Meson 0.44, but for the documentation at
      least 0.46 is needed because of a new functionality of
      gnome.gdbus_codegen(). In this way we can still build on Travis CI
      (without documentation).
  15. 24 Sep, 2018 1 commit
  16. 06 Aug, 2018 1 commit
  17. 01 Aug, 2018 1 commit
    • Thomas Haller's avatar
      all: avoid byte ordering issue for IP4Config's Nameservers/WinsServers on D-Bus · 4eeb4b1b
      Thomas Haller authored
      Some properties in NetworkManager's D-Bus API are IPv4 addresses
      in network byte order (big endian). That is problematic.
      It is no problem, when the NetworkManager client runs on the same
      host. That is the case with libnm, which does not support to be used
      remotely for the time being.
      It is a problem for an application that wants to access the D-Bus
      interface of NetworkManager remotely. Possibly, such an application
      would be implemented in two layers:
       - one layer merely remotes D-Bus, without specific knowledge of
         NetworkManager's API.
       - a higher layer which accesses the remote D-Bus interface of NetworkManager.
         Preferably it does so in an agnostic way, regardless of whether it runs
         locally or remotely.
      When using a D-Bus library, all accesses to 32 bit integers are in
      native endianness (regardless of how the integer is actually encoded
      on the lower layers). Likewise, D-Bus does not support annotating integer
      types in non-native endianness. There is no way to annotate an integer
      type "u" to be anything but native order.
      That means, when remoting D-Bus at some point the endianness must be
      But by looking at the D-Bus introspection alone, it is not possible
      to know which property need correction and which don't. One would need
      to understand the meaning of the properties.
      That makes it problematic, because the higher layer of the application,
      which knows that the "Nameservers" property is supposed to be in network
      order, might not easily know, whether it must correct for endianness.
      Deprecate IP4Config properties that are only accessible with a particular
      endianness, and add new properties that expose the same data in an
      agnostic way.
      Note that I added "WinsServerData" to be a plain "as", while
      "NameserverData" is of type "aa{sv}". There is no particularly strong
      reason for these choices, except that I could imagine that it could be
      useful to expose additional information in the future about nameservers
      (e.g. are they received via DHCP or manual configuration?). On the other
      hand, WINS information likely won't get extended in the future.
      Also note, libnm was not modified to use the new D-Bus fields. The
      endianness issue is no problem for libnm, so there is little reason to
      change it (at this point).
  18. 10 Jul, 2018 2 commits
  19. 26 Jun, 2018 2 commits
  20. 15 Jun, 2018 1 commit
  21. 13 Jun, 2018 1 commit
  22. 11 Jun, 2018 1 commit
    • Lubomir Rintel's avatar
      settings-connection: expose Filename property on D-Bus · 87f5ff69
      Lubomir Rintel authored
      This allows implementing some convenience features in nmcli -- listing
      the backing store for the connection in "nmcli c show", and using the
      filename for specifying connection in "nmcli c up/down".
      Eventually, paired with ReloadConnections(), this could be used to
      implement something similar to what "systemctl edit" does for units
      (though we'd need to pick another command name as we aready use
      "nmcli c edit" for something different).
  23. 18 Apr, 2018 1 commit
  24. 16 Apr, 2018 1 commit
    • Thomas Haller's avatar
      all: add D-Bus property "Flags" for Settings.Connection interface · acc8244c
      Thomas Haller authored
      The D-Bus interface already has a boolean property "Unsaved".
      While that is nicer too look at (in the API), adding a new flag
      is very cumbersome, and also has more overhead. For example,
      it requires extending the D-Bus API, all the way down to libnm.
      Add a flags argument, that will allow to add future boolean
      flags easier.
  25. 04 Apr, 2018 1 commit
    • Thomas Haller's avatar
      checkpoint: allow resetting the rollback timeout via D-Bus · f6730322
      Thomas Haller authored
      This allows to adjust the timeout of an existing checkpoint.
      The main usecase of checkpoints, is to have a fail-safe when
      configuring the network remotely. By allowing to reset the timeout,
      the user can perform a series of actions, and keep bumping the
      timeout. That way, the entire series is still guarded by the same
      checkpoint, but the user can start with short timeout, and
      re-adjust the timeout as he goes along.
      The libnm API only implements the async form (at least for now).
      Sync methods are fundamentally wrong with D-Bus, and it's probably
      not needed. Also, follow glib convenction, where the async form
      doesn't have the _async name suffix. Also, accept a D-Bus path
      as argument, not a NMCheckpoint instance. The libnm API should
      not be more restricted than the underlying D-Bus API. It would
      be cumbersome to require the user to lookup the NMCheckpoint
      instance first, especially since libnm doesn't provide an efficient
      or convenient lookup-by-path method. On the other hand, retrieving
      the path from a NMCheckpoint instance is always possible.
  26. 16 Feb, 2018 1 commit
  27. 10 Jan, 2018 2 commits
    • Beniamino Galvani's avatar
      ppp: introduce SetIfindex pppd plugin D-Bus method · dd98ada3
      Beniamino Galvani authored
      If IPV6CP terminates before IPCP, pppd enters the RUNNING phase and we
      start IP configuration without having an IP interface set, which
      triggers assertions.
      Instead, add a SetIfindex() D-Bus method that gets called by the
      plugin when pppd becomes RUNNING. The method sets the IP ifindex of
      the device and starts IP configuration.
    • Inigo Martínez's avatar
      meson: Improve dependency system · 5e16bcf2
      Inigo Martínez authored
      Some targets are missing dependencies on some generated sources in
      the meson port. These makes the build to fail due to missing source
      files on a highly parallelized build.
      These dependencies have been resolved by taking advantage of meson's
      internal dependencies which can be used to pass source files,
      include directories, libraries and compiler flags.
      One of such internal dependencies called `core_dep` was already in
      use. However, in order to avoid any confusion with another new
      internal dependency called `nm_core_dep`, which is used to include
      directories and source files from the `libnm-core` directory, the
      `core_dep` dependency has been renamed to `nm_dep`.
      These changes have allowed minimizing the build details which are
      inherited by using those dependencies. The parallelized build has
      also been improved.
  28. 05 Jan, 2018 1 commit
    • Beniamino Galvani's avatar
      ip-tunnel: add support for tunnel flags · da4c9e51
      Beniamino Galvani authored
      Implement support for IP tunnel flags. Currently only some IPv6 tunnel
      flags are supported. Example:
       # nmcli connection add type ip-tunnel mode ip6ip6 \
         ip-tunnel.flags ip6-ign-encap-limit,ip6-use-orig-tclass \
         ifname abc ip-tunnel.parent ens8 ipv4.method disabled \
         ipv6.method manual ipv6.address ::8888 remote ::42
       # ip -d l
        61: abc@ens8: <NOARP,UP,LOWER_UP> mtu 1460 qdisc noqueue ...
          link/tunnel6 :: brd ::42 promiscuity 0
          ip6tnl ip6ip6 remote ::42 local :: dev ens8 encaplimit none
          hoplimit 0 tclass inherit ...