1. 12 Feb, 2019 4 commits
  2. 11 Feb, 2019 1 commit
  3. 06 Feb, 2019 1 commit
  4. 05 Feb, 2019 2 commits
  5. 04 Feb, 2019 6 commits
  6. 24 Jan, 2019 1 commit
  7. 07 Jan, 2019 1 commit
    • 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
  8. 30 Dec, 2018 1 commit
  9. 20 Dec, 2018 1 commit
  10. 19 Dec, 2018 2 commits
    • Thomas Haller's avatar
      all: don't use static buffer for nm_utils_inet*_ntop() · a51c09dc
      Thomas Haller authored
      While nm_utils_inet*_ntop() accepts a %NULL buffer to fallback
      to a static buffer, don't do that.
      
      I find the possibility of using a static buffer here error prone
      and something that should be avoided. There is of course the downside,
      that in some cases it requires an additional line of code to allocate
      the buffer on the stack as auto-variable.
      a51c09dc
    • Aleksander Morgado's avatar
      settings,gsm: deprecate and stop using 'number' property · 6ed21e83
      Aleksander Morgado authored
      The 'number' property in GSM settings is a legacy thing that comes
      from when ModemManager used user-provided numbers, if any, to connect
      3GPP modems.
      
      Since ModemManager 1.0, this property is completely unused for 3GPP
      modems, and so it doesn't make sense to use it in the NetworkManager
      settings. Ofono does not use it either.
      
      For AT+PPP-based 3GPP modems, the 'number' to call to establish the
      data connection is decided by ModemManager itself, e.g. for standard
      GSM/UMTS/LTE modems it will connect a given predefined PDP context,
      and for other modems like Iridium it will have the number to call
      hardcoded in the plugin itself.
      
      https://github.com/NetworkManager/NetworkManager/pull/261
      6ed21e83
  11. 13 Dec, 2018 2 commits
  12. 12 Dec, 2018 2 commits
    • Beniamino Galvani's avatar
      ifcfg-rh: fix persisting sriov setting · d48f389c
      Beniamino Galvani authored
      The writer should write all properties of the sriov setting when the
      setting exists without additional logic. Likewise, the reader should
      instantiate a sriov setting when any sriov key is present and blindly
      set properties from keys.
      
      The old code did not always preserve the presence of a sriov setting
      after a write/read cycle.
      
      Fixes: c02d1c48
      d48f389c
    • 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
  13. 03 Dec, 2018 3 commits
    • Thomas Haller's avatar
      keyfile: add helper functions to record loaded UUID files · 3fc5765e
      Thomas Haller authored
      This code will be used later.
      
      We want to remember which keyfiles are currently loaded (or hidden).
      
      With the addition or multiple keyfile directories (soon), there are
      two cases where this matters:
      
       - if there are multiple keyfiles which reference the same UUID,
         we can only load one of them. That is already a problem today
         with only one keyfile directory, where multiple files can reference
         the same UUID.
         The implementation will pick the file based on priorities (like
         the file modification date). However, the user may call explicitly
         call `nmcli connection load`. In that case, we cannot reload
         all files to find out whether the to be loaded file is hidden
         according to the defined priorities. We cannot do that, because we
         must not make decisions based on files on disk, which we are not told
         to reload. So, during a `nmcli connection load` we must look at
         unrelated files, to determine how to load the file.
         Instead, we do allow the user to load any file, even if it would be
         shadowed by other files. When we do that, we may want to persist which
         file is currently loaded, so that a service restart and a `nmcli connection
         reload` does not undo the load again. This can be later later be solved by
         writing a symlink
      
             "/var/run/NetworkManager/system-connections/.loaded-$UUID.nmkeyfile"
      
         which targets the currently active file.
      
       - if a profile was loaded from read-only persistant storage, the user
         may still delete the profile. We also need to remember the deletion
         of the file. That will be achieved by symlinking "/dev/null" as
         "/etc/NetworkManager/system-connections/.loaded-$UUID.nmkeyfile".
      
      Add helper functions to read and write these symlinks.
      3fc5765e
    • Thomas Haller's avatar
      f7de10ac
    • Thomas Haller's avatar
      keyfile/tests: add tests for ignoring keyfile filenames · 4d8ce80e
      Thomas Haller authored
      In particular, have a full path (with slashes), and a filename
      with trailing slash (a directory).
      4d8ce80e
  14. 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.
      b385ad01
  15. 23 Oct, 2018 7 commits
  16. 22 Oct, 2018 1 commit
  17. 19 Oct, 2018 1 commit
  18. 18 Oct, 2018 1 commit
    • Thomas Haller's avatar
      keyfile: write keyfiles to "/run" directory with ".nmconnection" file suffix · 648c256b
      Thomas Haller authored
      For profiles in "/etc/NetworkManager/system-connections", we did not enforce
      that the keyfiles have a special suffix, nor did we generate the
      filenames in such a manner. In hindsight, I think that was a mistake.
      
      Recently we added "/run/NetworkManager/system-connections" as additional
      keyfile directory. Enforce a suffix and write keyfiles with such a name.
      
      In principle, we could also start writing keyfiles in /etc with the
      same suffix. But let's not do that, because we anyway cannot enforce
      it.
      
      An ugly part is, that during `nmcli connection load` we need to
      determine whether the to-be-loaded connection is under /etc or /run.
      Preferably, we would allow any kind of symlinking as what matters
      is the file object (inode) and not the path. Anyway, we don't do
      that but compare plain paths. That means, paths which are not
      in an expected form, will be rejected. In particular, the paths
      starting with "/run/..." and "/var/run/..." will be treated differently,
      and one of them will be rejected.
      
      Note that ifcfg-rh plugin strictly enforces that the path
      starts with IFCFG_DIR as well. So, while this is a breaking
      change for keyfile, I think it's reasonable.
      648c256b
  19. 12 Oct, 2018 1 commit
  20. 10 Oct, 2018 1 commit