1. 18 Apr, 2019 1 commit
    • Thomas Haller's avatar
      shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core · 284ac92e
      Thomas Haller authored
      "libnm-core" implements common functionality for "NetworkManager" and
      "libnm".
      
      Note that clients like "nmcli" cannot access the internal API provided
      by "libnm-core". So, if nmcli wants to do something that is also done by
      "libnm-core", , "libnm", or "NetworkManager", the code would have to be
      duplicated.
      
      Instead, such code can be in "libnm-libnm-core-{intern|aux}.la".
      Note that:
      
        0) "libnm-libnm-core-intern.la" is used by libnm-core itsself.
           On the other hand, "libnm-libnm-core-aux.la" is not used by
           libnm-core, but provides utilities on top of it.
      
        1) they both extend "libnm-core" with utlities that are not public
           API of libnm itself. Maybe part of the code should one day become
           public API of libnm. On the other hand, this is code for which
           we may not want to commit to a stable interface or which we
           don't want to provide as part of the API.
      
        2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core"
           and thus directly available to "libnm" and "NetworkManager".
           On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm"
           and "NetworkManager".
           Both libraries may be statically linked by libnm clients (like
           nmcli).
      
        3) it must only use glib, libnm-glib-aux.la, and the public API
           of libnm-core.
           This is important: it must not use "libnm-core/nm-core-internal.h"
           nor "libnm-core/nm-utils-private.h" so the static library is usable
           by nmcli which couldn't access these.
      
      Note that "shared/nm-meta-setting.c" is an entirely different case,
      because it behaves differently depending on whether linking against
      "libnm-core" or the client programs. As such, this file must be compiled
      twice.
      
      (cherry picked from commit af07ed01)
      284ac92e
  2. 27 Mar, 2019 2 commits
    • Thomas Haller's avatar
      libnm: add NMIPRoutingRule API · 7fb23b0a
      Thomas Haller authored
      Add NMIPRoutingRule API with a few basic rule properties. More
      properties will be added later as we want to support them.
      
      Also, add to/from functions for string/GVariant representations.
      These will be needed to persist/load/exchange rules.
      
      The to-string format follows the `ip rule add` syntax, with the aim
      to be partially compatible. Full compatibility is not possible though,
      for various reasons (see code comment).
      7fb23b0a
    • Thomas Haller's avatar
      d0727509
  3. 26 Mar, 2019 3 commits
  4. 25 Mar, 2019 2 commits
  5. 24 Mar, 2019 2 commits
  6. 13 Mar, 2019 4 commits
  7. 07 Mar, 2019 2 commits
    • Thomas Haller's avatar
      libnm: rename and expose nm_utils_base64secret_decode() in libnm · 0d178a96
      Thomas Haller authored
      A NetworkManager client requires an API to validate and decode
      a base64 secret -- like it is used by WireGuard. If we don't have
      this as part of the API, it's inconvenient. Expose it.
      
      Rename it from _nm_utils_wireguard_decode_key(), to give it a more
      general name.
      
      Also, rename _nm_utils_wireguard_normalize_key() to
      nm_utils_base64secret_normalize(). But this one we keep as internal
      API. The user will care more about validating and decoding the base64
      key. To convert the key back to base64, we don't need a public API in
      libnm.
      
      This is another ABI change since 1.16-rc1.
      
      (cherry picked from commit e46ba018)
      0d178a96
    • Thomas Haller's avatar
      libnm: rename and expose nm_utils_base64secret_decode() in libnm · e46ba018
      Thomas Haller authored
      A NetworkManager client requires an API to validate and decode
      a base64 secret -- like it is used by WireGuard. If we don't have
      this as part of the API, it's inconvenient. Expose it.
      
      Rename it from _nm_utils_wireguard_decode_key(), to give it a more
      general name.
      
      Also, rename _nm_utils_wireguard_normalize_key() to
      nm_utils_base64secret_normalize(). But this one we keep as internal
      API. The user will care more about validating and decoding the base64
      key. To convert the key back to base64, we don't need a public API in
      libnm.
      
      This is another ABI change since 1.16-rc1.
      e46ba018
  8. 05 Mar, 2019 2 commits
  9. 22 Feb, 2019 3 commits
    • Thomas Haller's avatar
      all: move nm_utils_hexstr2bin*() to shared · 53b747ff
      Thomas Haller authored
      libnm exposes simplified variants of hexstr2bin in its public API. I
      think that was a mistake, because libnm should provide NetworkManager
      specific utils. It should not provide such string functions.
      
      However, nmcli used to need this, so it was added to libnm.
      
      The better approach is to add it to our internally shared static
      library, so that all interested components can make use of it.
      53b747ff
    • Thomas Haller's avatar
      e148ec07
    • Thomas Haller's avatar
      libnm,cli: add NMSettingWireGuard · b521f426
      Thomas Haller authored
      For now only add the core settings, no peers' data.
      
      To support peers and the allowed-ips of the peers is more complicated
      and will be done later. It's more complicated because these are nested
      lists (allowed-ips) inside a list (peers). That is quite unusual and to
      conveniently support that in D-Bus API, in keyfile format, in libnm,
      and nmcli, is a effort.
      Also, it's further complicated by the fact that each peer has a secret (the
      preshared-key). Thus we probably need secret flags for each peer, which
      is a novelty as well (until now we require a fixed set of secrets per
      profile that is well known).
      b521f426
  10. 14 Feb, 2019 2 commits
    • Thomas Haller's avatar
      libnm: add NMSockAddrEndpoint API · 713e879d
      Thomas Haller authored
      NMSockAddrEndpoint is an immutable structure that contains the endpoint
      string of a service. It also includes the (naive) parsing of the host and
      port/service parts.
      
      This will be used for the endpoint of WireGuard's peers. But since endpoints
      are not something specific to WireGuard, give it a general name (and
      purpose) independent from WireGuard.
      
      Essentially, this structure takes a string in a manner that libnm
      understands, and uses it for node and service arguments for
      getaddrinfo().
      
      NMSockAddrEndpoint allows to have endpoints that are not parsable into
      a host and port part. That is useful because our settings need to be
      able to hold invalid values. That is for forward compatibility (server
      sends a new endpoint format) and for better error handling (have
      invalid settings that can be constructed without loss, but fail later
      during the NMSetting:verify() step).
      713e879d
    • Thomas Haller's avatar
      libnm/trivial: rename NM_SETTING_SECRET_FLAG_ALL flag (formerly NM_SETTING_SECRET_FLAGS_ALL) · 28c53ea3
      Thomas Haller authored
      It should mirror the naming pattern of the flags.
      28c53ea3
  11. 04 Feb, 2019 3 commits
    • Thomas Haller's avatar
      libnm,core: make for-each-secret implementation virtual functions of NMSetting · 353e619c
      Thomas Haller authored
      We already need to special handle regular settings (with secrets as
      GObject properties) and VPN secrets.
      
      Next, we will also need to special handle WireGuard peers, which can
      have secrets too.
      
      Move the code to a virtual function, so that "nm-connection.c" and
      "nm-setting.c" does not have explicit per-setting knowledge.
      353e619c
    • Thomas Haller's avatar
      libnm,core: move _nm_connection_for_each_secret() from core to libnm-core · 79a0238c
      Thomas Haller authored
      _nm_connection_for_each_secret() (formerly for_each_secret()) and
      _nm_connection_find_secret() (formerly find_secret()) operate on a
      GVariant of secrets. For that, they implement certain assumptions
      of how to handle secrets. For example, it must special-case VPN settings,
      because there is no generic abstraction to handle regular secret and VPN
      secrets the same.
      
      Such special casing should only be done in libnm-core, at one place.
      
      Move the code to libnm-core as internal API.
      79a0238c
    • Thomas Haller's avatar
      libnm: extend nm_setting_enumerate_values() to support non-GObject base properties · 52368678
      Thomas Haller authored
      While nm_setting_enumerate_values() should not be used anymore, still
      extend it to make it workable also for properties that are not based on
      GObject properties.
      52368678
  12. 01 Feb, 2019 1 commit
    • Thomas Haller's avatar
      wifi-p2p: rename files for consistent Wi-Fi P2P naming · 0420fa1f
      Thomas Haller authored
      We named the types inconsistently:
      
        - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h")
      
        - "p2p" ("libnm/nm-p2p-peer.h")
      
        - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h")
      
      It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi"
      specific name. It's not just peer-to-peer, it's Wi-Fi P2P.
      Yes, there is an inconsistency now, because there is already
      "libnm/nm-access-point.h".
      
      It seems to me (from looking at the internet), that the name "Wi-Fi P2P"
      is more common than "P2P Wi-Fi" -- although both are used. There is also
      the name "Wi-Fi Direct". But it's not clear which name should be
      preferred here, so stick to "Wi-Fi P2P".
      
      In this first commit only rename the files. The following commit will
      rename the content.
      0420fa1f
  13. 27 Jan, 2019 1 commit
  14. 11 Jan, 2019 2 commits
  15. 10 Jan, 2019 1 commit
  16. 07 Jan, 2019 5 commits
    • Thomas Haller's avatar
      libnm-core: add _nm_setting_secret_flags_valid() helper · a5b20ba2
      Thomas Haller authored
      Secret-flags are flags, but most combinations don't actually make sense
      and maybe should be rejected. Anyway, that is not done, and most places
      just check that there are no unknown flags set.
      
      Add _nm_setting_secret_flags_valid() to perform the check at one place
      instead of having the implementation at various places.
      a5b20ba2
    • Thomas Haller's avatar
      libnm: move sorting of settings out of nm_setting_enumerate_values() and cache it · 7cc24629
      Thomas Haller authored
      The property infos are already sorted by name. As nm_setting_enumerate_values()
      now uses that information, in most cases there is nothing to sort.
      
      The only instance is NMSettingConnection, which has a different
      sort-order. At least for some purposes, not all:
      
        - nm_setting_enumerate_values(), obviously.
      
        - nm_setting_enumerate_values() is called by keyfile writer. That
          means, keyfile writer will persist properties in a sorted way.
      
      Cache the property list with alternative sorting also in the
      setting-meta data, instead of calculating it each time.
      
      Beside caching the information, this has the additional benefit that
      this kind of sorting is now directly available, without calling
      nm_setting_enumerate_values(). Meaning, we can implement keyfile writer
      without using nm_setting_enumerate_values().
      7cc24629
    • Thomas Haller's avatar
      libnm,core: add _nm_connection_aggregate() to replace nm_connection_for_each_setting_value() · 7771473f
      Thomas Haller authored
      We should no longer use nm_connection_for_each_setting_value() and
      nm_setting_for_each_value(). It's fundamentally broken as it does
      not work with properties that are not backed by a GObject property
      and it cannot be fixed because it is public API.
      
      Add an internal function _nm_connection_aggregate() to replace it.
      
      Compare the implementation of the aggregation functionality inside
      libnm with the previous two checks for secret-flags that it replaces:
      
      - previous approach broke abstraction and require detailed knowledge of
        secret flags. Meaning, they must special case NMSettingVpn and
        GObject-property based secrets.
        If we implement a new way for implementing secrets (like we will need
        for WireGuard), then this the new way should only affect libnm-core,
        not require changes elsewhere.
      
      - it's very inefficient to itereate over all settings. It involves
        cloning and sorting the list of settings, and retrieve and clone all
        GObject properties. Only to look at secret properties alone.
      
      _nm_connection_aggregate() is supposed to be more flexible then just
      the two new aggregate types that perform a "find-any" search. The
      @arg argument and boolean return value can suffice to implement
      different aggregation types in the future.
      
      Also fixes the check of NMAgentManager for secret flags for VPNs
      (NM_CONNECTION_AGGREGATE_ANY_SYSTEM_SECRET_FLAGS). A secret for VPNs
      is a property that either has a secret or a secret-flag. The previous
      implementation would only look at present secrets and
      check their flags. It wouldn't check secret-flags that are
      NM_SETTING_SECRET_FLAG_NONE, but have no secret.
      7771473f
    • Thomas Haller's avatar
      libnm: pass serialization flags to settings synth_func() · e8bf89a9
      Thomas Haller authored
      We will need access to the serialization flags from within the synth_func().
      
      That will be for WireGuard's peers. Peers are a list of complex, structured
      elements, and some fields (the peer's preshared-key) are secret and
      others are not. So when serializing the peers, we need to know whether
      to include secrets or not.
      
      Instead of letting _nm_setting_to_dbus() check the flags, pass them
      down.
      
      While at it, don't pass the property_name argument. Instead, pass the
      entire meta-data information we have. Most synth functions don't care
      about the property or the name either way. But we should not pre-filter
      information that we have at hand. Just pass it to the synth function.
      If the synth function would be public API, that would be a reason to be
      careful about what we pass. But it isn't and it only has one caller.
      So passing it along is fine. Also, do it now when adding the flags
      argument, as we touch all synth implementations anyway.
      e8bf89a9
    • Thomas Haller's avatar
      Revert "libnm-core: don't serialize synthetic properties in nm_setting_to_string()" · 1b361aae
      Thomas Haller authored
      We shall not shortcut the synth function. If the synth function is
      unhappy about a missing NMConnection argument, then that needs to be
      fixed.
      
      So, revert 395c385b and fix the issue in nm_setting_wireless_get_security()
      differently. I presume that is the only place that caused problems,
      since the history of the patch does not clealy show what the problem
      was.
      
      This reverts commit 395c385b.
      1b361aae
  17. 19 Dec, 2018 1 commit
    • Thomas Haller's avatar
      libnm: add internal API nm_utils_inet*_ntop_dup() · 898f7a56
      Thomas Haller authored
      In quite some cases we need the string representation on the heap.
      
      While nm_utils_inet*_ntop() accepts NULL as output buffer to fallback
      to a static buffer, such usage of a static buffer is discouraged.
      So, we actually should always allocate a temporaray buffer on the
      stack. But that is cumbersome to write.
      
      Add simple wrappers that makes calling this more convenient.
      898f7a56
  18. 12 Dec, 2018 1 commit
    • Beniamino Galvani's avatar
      cli: strictly validate SR-IOV attributes · 769e0726
      Beniamino Galvani authored
      Report an error when the user tries to add an unknown attribute
      instead of silently accepting (and ignoring) it.
      
      Note that this commit also changes the behavior of public API
      nm_utils_sriov_vf_from_str() to return an error when an unknown
      attribute is found. I think the previous behavior was buggy as wrong
      attributes were simply ignored without any way for the user to know.
      
      Fixes: a9b4532f
      769e0726
  19. 07 Nov, 2018 1 commit
  20. 31 Oct, 2018 1 commit