1. 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
  2. 07 Jun, 2018 1 commit
  3. 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
  4. 01 Jun, 2018 1 commit
  5. 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
  6. 18 Apr, 2018 1 commit
  7. 18 Feb, 2018 1 commit
  8. 15 Feb, 2018 1 commit
  9. 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
  10. 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
  11. 27 Dec, 2017 1 commit
  12. 21 Dec, 2017 2 commits
  13. 19 Dec, 2017 1 commit
  14. 13 Dec, 2017 1 commit
  15. 28 Nov, 2017 1 commit
  16. 06 Nov, 2017 4 commits
  17. 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
  18. 31 Oct, 2017 1 commit
  19. 30 Oct, 2017 1 commit
  20. 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
  21. 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
  22. 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
  23. 26 Sep, 2017 1 commit
  24. 13 Sep, 2017 2 commits
  25. 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
  26. 05 Sep, 2017 3 commits
  27. 30 Aug, 2017 1 commit
  28. 22 Jun, 2017 1 commit
  29. 13 Jun, 2017 1 commit
    • Thomas Haller's avatar
      device: don't set MTU of device unless explicitly configured · 4ca3002b
      Thomas Haller authored
      Since commit 2b51d396 "device: merge branch 'th/device-mtu-bgo777251'",
      we always set the MTU for certain device types during activation. Even
      if the MTU is neither specified via the connection nor other means, like
      DHCP.
      
      Revert that change. On activation, if nothing explicitly configures the
      MTU, leave it unchanged. This is like what we do with ethernet's
      cloned-mac-address, which has a default value "preserve".
      So, as last resort the default value for MTU is now 0 (don't change),
      instead of depending on the device type.
      
      Note that you also can override the default value in global
      configuration via NetworkManager.conf.
      
      This behavior makes sense, because whenever NM actively resets the MTU,
      it remembers the previous value and restores it when deactivating
      the connection. That wasn't implemented before 2b51d396, and the
      MTU would depend on which connection was previously active. That
      is no longer an issue as the MTU gets reset when deactivating.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1460760
      4ca3002b
  30. 31 May, 2017 1 commit
  31. 24 May, 2017 1 commit