1. 05 Mar, 2019 1 commit
  2. 08 Feb, 2019 1 commit
  3. 05 Feb, 2019 2 commits
  4. 31 Jan, 2019 2 commits
  5. 24 Jan, 2019 1 commit
  6. 04 Jan, 2019 1 commit
    • Andrew Zaborowski's avatar
      cli: reuse connections in nmcli dev wifi con · f293373b
      Andrew Zaborowski authored
      Try to locate an existing connection before creating a new one when
      handling "nmcli device wifi connect".  This allows WPA-Enterprise
      networks to be activated this way, consistent with the comment that this
      command is equivalent to clicking on an SSID in a GUI client.
  7. 20 Dec, 2018 1 commit
  8. 12 Dec, 2018 1 commit
  9. 11 Dec, 2018 2 commits
    • Thomas Haller's avatar
      core: fix match spec behavior for a list of all "except:" · a7ef23b3
      Thomas Haller authored
      If the spec specifies only negative matches (and none of them matches),
      then the result shall be positive.
          [connection*] match-device=except:dhcp-plugin:dhclient
          [connection*] match-device=except:interface-name:eth0
          [.config] enabled=except:nm-version:1.14
      should be the same as:
          [connection*] match-device=*,except:dhcp-plugin:dhclient
          [connection*] match-device=*,except:interface-name:eth0
          [.config] enabled=*,except:nm-version:1.14
      and match by default. Previously, such specs would never yield a
      positive match, which seems wrong.
      Note that "except:" already has a special meaning. It is not merely
      "not:". That is because we don't support "and:" nor grouping, but all
      matches are combined by an implicit "or:". With such a meaning, having
      a "not:" would be unclear to define. Instead it is defined that any
      "except:" match always wins and makes the entire condition to explicitly
      not match. As such, it makes sense to treat a match that only consists
      of "except:" matches special.
      This is a change in behavior, but the alternative meaning makes
      little sense.
    • Thomas Haller's avatar
      connectivity: honor "main.systemd-resolved" setting to not resolve names first · c7d88645
      Thomas Haller authored
      If the user disabled systemd-resolved, two things seem apparent:
       - the user does not want us to use systemd-resolved
       - NetworkManager is not pushing the DNS configuration to
      It seems to me, we should not consult systemd-resolved in that case.
  10. 04 Dec, 2018 1 commit
    • Andrew Zaborowski's avatar
      cli: reuse connections in nmcli dev wifi con · 35932375
      Andrew Zaborowski authored
      Try to locate an existing connection before creating a new one when
      handling "nmcli device wifi connect".  This allows WPA-Enterprise
      networks to be activated this way, consistent with the comment that this
      command is equivalent to clicking on an SSID in a GUI client.
  11. 01 Dec, 2018 2 commits
  12. 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.
  13. 28 Nov, 2018 1 commit
  14. 23 Nov, 2018 1 commit
  15. 14 Nov, 2018 3 commits
  16. 13 Nov, 2018 2 commits
    • Thomas Haller's avatar
      man: document global connection default for "ipv4.dns-priority" · 207a9a22
      Thomas Haller authored
      ... and "ipv6.dns-priority".
      Fixes: 77ded12d
    • Thomas Haller's avatar
      man: clarify blocking autoconnect during `nmcli connection down` · 17f9801e
      Thomas Haller authored
      Manually disconnecting a profile of course blocks autoconnect of the
      same profile. Otherwise, the profile would likely re-activate right
      away, which is clearly against the users intention. If the users just
      want to re-activate the profile, they should issue `nmcli connection up`
      instead, with does a full down and up cycle.
      This is more interesting for profiles that have 'connection.multi-connect'
      set to 'multiple'. Would you expect that manually deactivating such a
      profile blocks autoconnect of the profile on all devices? Maybe
      yes, maybe not. Currently that is indeed the case and autoconnect gets
      blocked regardless of multi-connect.
  17. 05 Nov, 2018 2 commits
  18. 01 Nov, 2018 1 commit
    • Thomas Haller's avatar
      device: add "dhcp-plugin" match spec for device · b9eb264e
      Thomas Haller authored
      The need for this is the following:
      "ipv4.dhcp-client-id" can be specified via global connection defaults.
      In absence of any configuration in NetworkManager, the default depends
      on the DHCP client plugin. In case of "dhclient", the default further
      depends on /etc/dhcp.
      For "internal" plugin, we may very well want to change the default
      client-id to "mac" by universally installing a configuration
      However, if we the user happens to enable "dhclient" plugin, this also
      forces the client-id and overrules configuration from /etc/dhcp. The real
      problem is, that dhclient can be configured via means outside of NetworkManager,
      so our defaults shall not overwrite defaults from /etc/dhcp.
      With the new device spec, we can avoid this issue:
      This will be part of the solution for rh#1640494. Note that merely
      dropping a configuration snippet is not yet enough. More fixes for
      DHCP will follow. Also, bug rh#1640494 may have alternative solutions
      as well. The nice part of this new feature is that it is generally
      useful for configuring connection defaults and not specifically for
      the client-id issue.
      Note that this match spec is per-device, although the plugin is selected
      globally. That makes some sense, because in the future we may or may not
      configure the DHCP plugin per-device or per address family.
  19. 26 Oct, 2018 1 commit
  20. 25 Oct, 2018 1 commit
  21. 17 Oct, 2018 1 commit
    • Thomas Haller's avatar
      man: document `nmcli device connect` behaviour · 1b732e28
      Thomas Haller authored
      Already since 1.0.0 release and commit "37846781 cli: create a connection
      if none exist in 'nmcli dev connect' (rh #1113941)", device-connect can
      also create a profile.
      That is useful, in particular as opposed to
        $ nmcli connection up ifname "$DEVICE"
      which wouldn't create a profile (ever).
      Document it.
  22. 28 Sep, 2018 2 commits
  23. 24 Sep, 2018 1 commit
    • Lubomir Rintel's avatar
      dns: allow loading nm-dns-systemd-resolve alongside other DNS plugins · d4eb4cb4
      Lubomir Rintel authored
      Even when the system resolver is configured to something else that
      systemd-resolved, it still is a good idea to keep systemd-resolved up to
      date. If not anything else, it does a good job at doing per-interface
      resolving for connectivity checks.
      If for whatever reasons don't want NetworkManager to push the DNS data
      it discovers to systemd-resolved, the functionality can be disabled
  24. 21 Sep, 2018 2 commits
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      dns: write original DNS servers to /var/run/NetworkManager/no-stub-resolv.conf · 0dc673f0
      Thomas Haller authored
      When a DNS plugin is enabled (like "main.dns=dnsmasq" or "main.dns=systemd-resolved"),
      the name servers announced to the rc-manager are coerced to be
      Depending on the "main.rc-manager" setting, also "/etc/resolv.conf"
      contains only this coerced name server to the local caching service.
      The same is true for "/var/run/NetworkManager/resolv.conf" file, which
      contains what we would write to "/etc/resolv.conf" (depending on
      the "main.rc-manager" configuration).
      Write a new file "/var/run/NetworkManager/no-stub-resolv.conf", which contains
      the original name servers, uncoerced. Like "/var/run/NetworkManager/resolv.conf",
      this file is always written.
      The effect is, when one enables "main.dns=systemd-resolved", then there
      is still a file "no-stub-resolv.conf" with the same content as with
      The no-stub-resolv.conf may be a possible solution, when a user wants
      NetworkManager to update systemd-resolved, but still have a regular
      /etc/resolv.conf [1]. For that, the user could configure
      and symlink "/etc/resolv.conf" to "/var/run/NetworkManager/no-stub-resolv.conf".
      This is not necessarily the only solution for the problem and does not preclude
      options for updating systemd-resolved in combination with other DNS plugins.
      [1] #20
  25. 19 Sep, 2018 2 commits
  26. 18 Sep, 2018 2 commits
  27. 06 Sep, 2018 1 commit
  28. 06 Aug, 2018 1 commit