1. 16 Jan, 2017 1 commit
    • Beniamino Galvani's avatar
      libnm-core: add NMSettingMacsec · d252a99f
      Beniamino Galvani authored
      The new NMSettingMacsec contains information necessary to establish a
      MACsec connection. At the moment we support two different MACsec
      modes, both using wpa_supplicant: PSK and EAP.
      
      PSK mode is based on a static CAK key for the MACsec key agreement
      protocol, while EAP mode derives keys from a 802.1x authentication and
      thus requires the presence of a NMSetting8021x in the connection.
      d252a99f
  2. 28 Nov, 2016 1 commit
  3. 21 Nov, 2016 2 commits
  4. 15 Nov, 2016 1 commit
  5. 09 Nov, 2016 1 commit
  6. 03 Nov, 2016 1 commit
  7. 11 Oct, 2016 2 commits
  8. 06 Oct, 2016 1 commit
  9. 04 Oct, 2016 2 commits
  10. 27 Sep, 2016 1 commit
  11. 21 Sep, 2016 1 commit
  12. 06 Sep, 2016 1 commit
  13. 26 Aug, 2016 1 commit
  14. 17 Aug, 2016 2 commits
  15. 15 Aug, 2016 1 commit
  16. 10 Jul, 2016 1 commit
  17. 22 Jun, 2016 1 commit
  18. 16 Jun, 2016 2 commits
    • Thomas Haller's avatar
      shared: add "nm-utils/nm-vpn-plugin-utils.h" · 5d55492b
      Thomas Haller authored
      This file is only used by plugins and copied between them.
      
      It's purpose is to contain general utility functions that are
      only relevant for implementing NetworkManager's VPN plugins.
      
      In principle the utility functions could be part of libnm, however,
      there are a few problems with that:
        - if they are part of libnm, adding and using a new utility function
          requires the plugin to bump the required libnm version. Since you
          usally can work around/reimplement utility functions, this results
          in not using the API from libnm, not adding the API to libnm,
          and reimplementing it over and over in the plugin.
        - plugins compile both against libnm and libnm-glib. Thus, either
          the utility function would also be needed in libnm-glib, or again,
          it is not usable by the plugin.
      
      We must avoid that the utility functions diverge and no local
      modifications to these files should be made in the plugin.
      Instead, one special location of the utility functions shall be
      extended and re-imported (copied) to the plugin as needed.
      
      Add the files to NetworkManager's repository. Although they are not
      needed for NetworkManager itself, they are a different API provided
      by NetworkManager. An API that is reused and shared by copying the files
      around.
      5d55492b
    • Thomas Haller's avatar
      shared: move shared files to subdirectory "shared/nm-utils/" · 4b288136
      Thomas Haller authored
      The "shared" directory contains files that are possibly used by all components
      of NetworkManager repository.
      
      Some of these files are even copied as-is to other projects (VPN plugins, nm-applet)
      and used there without modification. Move those files to a separate directory.
      By moving them to a common directory, it is clearer that they belong
      together. Also, you can easier compare the copied versions to their
      original via
      
        $ diff -r ./shared/nm-utils/ /path/to/nm-vpn-plugin/shared/nm-utils/
      4b288136
  19. 15 Jun, 2016 1 commit
    • Thomas Haller's avatar
      libnm/vpn: add nm_vpn_editor_plugin_load_vt() · cf34211c
      Thomas Haller authored
      Let VPN plugins return a virtual function table to extend
      the API while bypassing libnm. This allows to add and use
      new functionality to VPN plugins without updating libnm.
      
      The actual definitions are in a header-only file
      "nm-vpn-editor-plugin-call.h", which can be copied to the
      caller/plugin.
      cf34211c
  20. 01 Jun, 2016 1 commit
    • Thomas Haller's avatar
      manager: add Reload() D-Bus command · 1d0e0eef
      Thomas Haller authored
      Add new Reload D-Bus command to reload NetworkManager configuration.
      
      For now, this is like sending SIGHUP to the process. There are several
      advantages here:
      
        - it is guarded via PolicyKit authentication while signals
          can only be sent by root.
      
        - the user can wait for the reload to be complete instead of sending
          an asynchronous signal. For now, we operation completes after
          nm_config_reload() returns, but later we could delay the response
          further until specific parts are fully reloaded.
      
        - SIGHUP reloads everything including re-reading configuration from
          disk while SIGUSR1 reloads just certain parts such as writing out DNS
          configuration anew.
          Now, the Reload command has a flags argument which is more granular
          in selecting parts which are to be reloaded. For example, via
          signals the user can:
      
            1) send SIGUSR1: this writes out the DNS configuration to
               resolv.conf and possibly reloads other parts without
               re-reading configuration and without restarting the DNS plugin.
            2) send SIGHUP: this reloads configuration from disk,
               writes out resolv.conf and restarts the DNS plugin.
      
          There is no way, to only restart the DNS plugin without also reloading
          everything else.
      1d0e0eef
  21. 10 May, 2016 2 commits
  22. 09 May, 2016 1 commit
  23. 28 Apr, 2016 2 commits
  24. 13 Apr, 2016 1 commit
  25. 12 Apr, 2016 3 commits
  26. 07 Apr, 2016 1 commit
  27. 05 Apr, 2016 5 commits