1. 27 Jun, 2018 1 commit
    • Thomas Haller's avatar
      logging: warn about invalid logging backends and drop "debug" backend · dbd48f26
      Thomas Haller authored
      "debug" was documentation in `man NetworkManager.conf` as a valid
      logging backend. However, it was completely ignored by
      nm_logging_syslog_openlog().
      In fact, it makes not sense. Passing debug = TRUE to
      nm_logging_syslog_openlog(), means that all messages will be
      printed to stderr in addition to syslog/journal. However, when
      NetworkManager is daemonizing, stderr is closed.
      Whether NetworkManager is daemonizing depends entirely on command
      line options --no-daemon and --debug. Hence, the logging backend "debug"
      from the configuration file either conflicts or is redundant.
      
      Also, adjust logging backend description in `man NetworkManager.conf`.
      
      Also, log a warning about invalid/unsupported logging backend.
      
      (cherry picked from commit 2ccf6168)
      dbd48f26
  2. 18 Jun, 2018 1 commit
    • Thomas Haller's avatar
      dispatcher: add NM_DISPATCHER_ACTION environment variable · 2800232b
      Thomas Haller authored
      Previously, the action was only passed as the first command line
      argument to the dispatcher scripts. Now, also set it via the
      "$NM_DISPATCHER_ACTION" environment variable.
      
      The main purpose is to have a particular, nm-dispatcher specific
      variable that is always set inside the dispatcher scripts.
      For example, imagine you have a script that can be either called by
      dispatcher or some other means (manually, or spawned via
      /etc/NetworkManager/dispatcher.d/11-dhclient).  Then it might make
      sense to differenciate from inside the script whether you are called
      by nm-dispatcher. But previously, there was no specific environment
      variable that was always set inside the dispatcher event. For example,
      with the "hostname" action there are no other environment variables.
      
      Now (with version 1.12), you can check for `test -n "$NM_DISPATCHER_ACTION"`.
      
      (cherry picked from commit ce961904)
      2800232b
  3. 13 Jun, 2018 1 commit
  4. 08 Jun, 2018 1 commit
    • Francesco Giudici's avatar
      libnm-core: add ipv6.dhcp-duid property · 7a0b6b17
      Francesco Giudici authored
      allow to specify the DUID to be used int the DHCPv6 client identifier
      option: the dhcp-duid property accepts either a hex string or the
      special values "lease", "llt", "ll", "stable-llt", "stable-ll" and
      "stable-uuid".
      
      "lease": give priority to the DUID available in the lease file if any,
               otherwise fallback to a global default dependant on the dhcp
               client used. This is the default and reflects how the DUID
               was managed previously.
      "ll": enforce generation and use of LL type DUID based on the current
            hardware address.
      "llt": enforce generation and use of LLT type DUID based on the current
             hardware address and a stable time field.
      "stable-ll": enforce generation and use of LL type DUID based on a
                   link layer address derived from the stable id.
      "stable-llt": enforce generation and use of LLT type DUID based on
                    a link layer address and a timestamp both derived from the
                    stable id.
      "stable-uuid": enforce generation and use of a UUID type DUID based on a
                     uuid generated from the stable id.
      7a0b6b17
  5. 07 Jun, 2018 1 commit
  6. 05 Jun, 2018 1 commit
    • Thomas Haller's avatar
      dns: change main.rc-manager=file behavior to always follow symlink · 644aa42f
      Thomas Haller authored
      With "main.rc-manager=file", if /etc/resolv.conf is a symlink, NetworkManager
      would follow the symlink and update the file instead.
      
      However, note that realpath() only returns a target, if the file actually
      exists. That means, if /etc/resolv.conf is a dangling symlink, NetworkManager
      would replace the symlink with a file.
      
      This was the only case in which NetworkManager would every change a symlink
      resolv.conf to a file. I think this is undesired behavior.
      
      This is a change in long established behavior. Although note that there were several
      changes regarding rc-manager settings in the past. See for example commit [1] and [2].
      
      Now, first still try using realpath() as before. Only if that fails, try
      to resolve /etc/resolv.conf as a symlink with readlink().
      
      Following the dangling symlink is likely not a problem for the user, it
      probably is even desired. The part that most likely can cause problems
      is if the destination file is not writable. That happens for example, if
      the destination's parent directories are missing. In this case, NetworkManager
      will now fail to write resolv.conf and log a warning. This has the potential of
      breaking existing setups, but it really is a mis-configuration from the user's
      side.
      
      This fixes for example the problem, if the user configures
      /etc/resolv.conf as symlink to /tmp/my-resolv.conf. At boot, the file
      would not exist, and NetworkManager would previously always replace the
      link with a plain file. Instead, it should follow the symlink and create
      the file.
      
      [1] 718fd224
      [2] 15177a34
      
      https://github.com/NetworkManager/NetworkManager/pull/127
      644aa42f
  7. 01 Jun, 2018 1 commit
  8. 10 May, 2018 1 commit
    • Lubomir Rintel's avatar
      cli: allow setting the colors with terminal-colors.d(5) · bcc9e58b
      Lubomir Rintel authored
      The present version of the specification is somewhat unclear at times,
      Unclear points were discussed with the maintainers [1] and probably
      some new version will address those.
      
      https://www.spinics.net/lists/util-linux-ng/msg15222.html
      
      Until then here's how the implementation copes with ambiguities
      (after the discussion with util-linux maintainers):
      
      1.) It is unclear whether multiple .schem files should override each
          other or be merged. We use the overriding behavior -- take the
          highest priority one and ignore the rest.
      
      2.) We assume "name.schem" is more specific than "@term.schem".
      
      3.) We assume the "Color name" are to be used as aliases for the color
          sequences and translate them to ANSI escape sequences.
      
      4.) The "Escape sequences" are of no use since the specification
          pretty much assumes an ANSI terminal and none of the sequences make
          any sense in ANSI color codes. We don't support them.
          accept that.
      
      5.) We don't implement TERMINAL_COLORS_DEBUG because it's unspecified
          what should it do.
      bcc9e58b
  9. 18 Apr, 2018 1 commit
  10. 18 Feb, 2018 1 commit
  11. 15 Feb, 2018 1 commit
  12. 16 Jan, 2018 1 commit
    • Masashi Honma's avatar
      wifi: add support for FILS · b4bbe517
      Masashi Honma authored
      The FILS(Fast Initial Link Setup) is a specification defined by IEEE 802.11ai to
      speed up roaming. This patch adds support of it.
      
      I have tested with these cases.
      +-----+-------------------------+----------------+
      | STA |            AP           |                |
      |FILS |         key-mgmt        |     result     |
      +-----+-------------------------+----------------+
      |  1  | WPA-EAP                 |       O        |
      +-----+-------------------------+----------------+
      |  1  | WPA-EAP-SHA256          |       O        |
      +-----+-------------------------+----------------+
      |  1  | FILS-SHA256             |       X        |
      +-----+-------------------------+----------------+
      |  1  | FILS-SHA384             |       X        |
      +-----+-------------------------+----------------+
      |  1  | WPA-EAP WPA-EAP-SHA256  |       O        |
      |     | FILS-SHA256 FILS-SHA384 | WPA-EAP-SHA256 |
      +-----+-------------------------+----------------+
      |  2  | WPA-EAP                 |       O        |
      +-----+-------------------------+----------------+
      |  2  | WPA-EAP-SHA256          |       O        |
      +-----+-------------------------+----------------+
      |  2  | FILS-SHA256             |       O        |
      +-----+-------------------------+----------------+
      |  2  | FILS-SHA384             |       O        |
      +-----+-------------------------+----------------+
      |  2  | WPA-EAP WPA-EAP-SHA256  |       O        |
      |     | FILS-SHA256 FILS-SHA384 | FILS-SHA384    |
      +-----+-------------------------+----------------+
      |  3  | WPA-EAP                 |       X        |
      +-----+-------------------------+----------------+
      |  3  | WPA-EAP-SHA256          |       X        |
      +-----+-------------------------+----------------+
      |  3  | FILS-SHA256             |       O        |
      +-----+-------------------------+----------------+
      |  3  | FILS-SHA384             |       O        |
      +-----+-------------------------+----------------+
      |  3  | WPA-EAP WPA-EAP-SHA256  |       O        |
      |     | FILS-SHA256 FILS-SHA384 | FILS-SHA384    |
      +-----+-------------------------+----------------+
      Signed-off-by: default avatarMasashi Honma <masashi.honma@gmail.com>
      b4bbe517
  13. 09 Jan, 2018 1 commit
    • Thomas Haller's avatar
      core: implement setting MDNS setting for systemd · c03a5349
      Thomas Haller authored
      The connection.mdns setting is a per-connection setting,
      so one might expect that one activated device can only have
      one MDNS setting at a time.
      
      However, with certain VPN plugins (those that don't have their
      own IP interface, like libreswan), the VPN configuration is merged
      into the configuration of the device. So, in this case, there
      might be multiple settings for one device that must be merged.
      
      We already have a mechanism for that. It's NMIP4Config. Let NMIP4Config
      track this piece of information. Although, stricitly speaking this
      is not tied to IPv4, the alternative would be to introduce a new
      object to track such data, which would be a tremendous effort
      and more complicated then this.
      
      Luckily, NMDnsManager and NMDnsPlugin are already equipped to
      handle multiple NMIPConfig instances per device (IPv4 vs. IPv6,
      and Device vs. VPN).
      
      Also make "connection.mdns" configurable via global defaults in
      NetworkManager.conf.
      c03a5349
  14. 27 Dec, 2017 1 commit
  15. 21 Dec, 2017 2 commits
  16. 19 Dec, 2017 1 commit
  17. 13 Dec, 2017 1 commit
  18. 28 Nov, 2017 1 commit
  19. 06 Nov, 2017 4 commits
  20. 02 Nov, 2017 1 commit
    • Thomas Haller's avatar
      all: move setting 802-1x.auth-retries to connection.auth-retries · 2730dc60
      Thomas Haller authored
      The number of authentication retires is useful also for passwords aside
      802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has
      a retry counter and uses a hard-coded value of 3.
      
      Move the setting, so that it can be used in general. Although it is still
      not implemented for other settings.
      
      This is an API and ABI break.
      2730dc60
  21. 31 Oct, 2017 1 commit
  22. 30 Oct, 2017 1 commit
  23. 09 Oct, 2017 1 commit
    • Thomas Haller's avatar
      all: rework configuring route table support by adding "route-table" setting · cc1ee1d2
      Thomas Haller authored
      We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change
      behavior for users that configured policy routing outside of NetworkManager,
      for example, via a dispatcher script. Users had to explicitly opt-in
      for NetworkManager to fully manage all routing tables.
      
      These settings were awkward. Replace them with new settings "ipv4.route-table"
      and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable
      development branch by removing recently added API.
      
      As before, a connection will have no route-table set by default. This
      has the meaning that policy-routing is not enabled and only the main table
      will be fully synced. Once the user sets a table, we recognize that and
      NetworkManager manages all routing tables.
      
      The new route-table setting has other important uses: analog to
      "ipv4.route-metric", it is the default that applies to all routes.
      Currently it only works for static routes, not DHCP, SLAAC,
      default-route, etc. That will be implemented later.
      
      For static routes, each route still can explicitly set a table, and
      overwrite the per-connection setting in "ipv4.route-table" and
      "ipv6.route-table".
      cc1ee1d2
  24. 04 Oct, 2017 1 commit
    • Thomas Haller's avatar
      core: cleanup autoconnect retry handling · cfb14ce1
      Thomas Haller authored
      - clearify in the manual page that setting retry to 1 means to try
        once, without retry.
      - log the initially set retry value in nm_settings_connection_get_autoconnect_retries().
      - use nm_settings_connection_get_autoconnect_retries() in
        nm_settings_connection_can_autoconnect().
      cfb14ce1
  25. 28 Sep, 2017 3 commits
    • Thomas Haller's avatar
      46dc919e
    • Thomas Haller's avatar
      device: add configuration option to mark devices as unmanaged · 5778bc6a
      Thomas Haller authored
      We already have various ways to mark a device as unmanaged.
      
      1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus
        at runtime.
      
      2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and
        keyfile.unmanaged-devices in NetworkManager.conf.
      
      3) at runtime, via D-Bus. This is persisted in the run state file
        and persists restarts (but not reboot).
      
      This adds another way via NetworkManager.conf file. Note that the
      existing keyfile.unmanaged-devices (above 2) is also a configuration
      optin in NetworkManager.conf. However it has various downsides:
      
        - it cannot be overwritten at runtime (see commit
          c210134b).
      
        - you can only explicitly mark a device as unmanaged. That means,
          you cannot use it to manage a device which is unmanaged due to
          a udev rule.
      
        - the name "keyfile.*" sounds like it's only relevant for the keyfile settings
          plugin. Nowadays the keyfile plugin is always loaded, so the option applies
          to NetworkManager in general.
      
      https://github.com/NetworkManager/NetworkManager/pull/29
      5778bc6a
    • Thomas Haller's avatar
      man: fix example for device section in NetworkManager.conf's manual · 286f21db
      Thomas Haller authored
      We currently don't support marking a device a managed/unmanaged via
      the [device] section. Eventually, I think we should, because the
      existing "keyfile.unmanaged-devices" looks keyfile specific (which
      it isn't). But more importantly, "keyfile.unmanaged-devices" sets the
      unmanaged flag NM_UNMANAGED_USER_SETTINGS, which cannot be overruled
      via D-Bus (see commit c210134b).
      A device.managed flag would make sense for a more sensible way to
      express configuration in NetworkManager.conf, which still can be
      overwritten via D-Bus.
      
      Anyway, it's not yet implemented. Fix the example.
      286f21db
  26. 26 Sep, 2017 1 commit
  27. 13 Sep, 2017 2 commits
  28. 11 Sep, 2017 1 commit
    • Thomas Haller's avatar
      device: enable support for ipv6.dhcp-timeout · 1aa36dde
      Thomas Haller authored
      - cleanup data type and use guint32 consistently. We might want to
        introduce a new "infinity" value. But since libnm's
        NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range
        0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity
        will have the numerical value G_MAXINT32, hence guint32 is just
        fine.
      
      - make use of existing ipv6.dhcp-timeout setting and add global
        default configuration in NetworkManager.conf
      
      - instead of having subclasses call nm_device_set_dhcp_timeout(),
        add a virtual function get_dhcp_timeout().
      1aa36dde
  29. 05 Sep, 2017 3 commits
  30. 30 Aug, 2017 1 commit
  31. 22 Jun, 2017 1 commit