1. 21 May, 2019 1 commit
  2. 05 Mar, 2019 2 commits
  3. 08 Feb, 2019 1 commit
  4. 05 Feb, 2019 2 commits
  5. 31 Jan, 2019 2 commits
  6. 24 Jan, 2019 1 commit
  7. 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.
      f293373b
  8. 20 Dec, 2018 1 commit
  9. 12 Dec, 2018 1 commit
  10. 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.
      
      Meaning:
      
          [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.
      a7ef23b3
    • 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
         systemd-resoved.
      
      It seems to me, we should not consult systemd-resolved in that case.
      c7d88645
  11. 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.
      35932375
  12. 01 Dec, 2018 2 commits
  13. 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
  14. 28 Nov, 2018 1 commit
  15. 23 Nov, 2018 1 commit
  16. 14 Nov, 2018 3 commits
  17. 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
      207a9a22
    • 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.
      17f9801e
  18. 05 Nov, 2018 2 commits
  19. 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
      snippet
      
          [connection-use-mac-client-id]
          ipv4.dhcp-client-id=mac
      
      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:
      
          [connection-dhcp-client-id]
          match-device=except:dhcp-plugin:dhclient
          ipv4.dhcp-client-id=mac
      
      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.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1640494
      b9eb264e
  20. 26 Oct, 2018 1 commit
  21. 25 Oct, 2018 1 commit
    • Thomas Haller's avatar
      man: fix "no-auto-default" state dir in NetworkManager.conf manual · ac90593c
      Thomas Haller authored
      Quote from `man NetworkManager.conf`:
      
        When the default wired connection is deleted or saved to a new
        persistent connection by a plugin, the device is added to a list in the
        file /run/NetworkManager/no-auto-default.state to prevent creating
        the default connection for that device again.
      
      "/run" is obviously wrong. Fix it.
      
      !33
      ac90593c
  22. 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.
      1b732e28
  23. 28 Sep, 2018 2 commits
  24. 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
      with:
      
        [main]
        systemd-resolved=false
      d4eb4cb4
  25. 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 127.0.0.1
      or 127.0.0.53.
      
      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
      "main.dns=default".
      
      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
      
          [main]
          dns=systemd-resolved
          rc-manager=unmanaged
      
      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
      0dc673f0
  26. 19 Sep, 2018 2 commits
  27. 18 Sep, 2018 2 commits