1. 25 Jul, 2018 1 commit
  2. 30 Jun, 2018 1 commit
  3. 29 Jun, 2018 2 commits
  4. 18 Jun, 2018 2 commits
    • 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
    • Thomas Haller's avatar
      release: update NEWS for 1.10.10 release · f8dfc436
      Thomas Haller authored
      1.10.10 was released still before 1.12.0. Update the
      NEWS to reflect that.
      f8dfc436
  5. 15 Jun, 2018 3 commits
  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. 31 May, 2018 1 commit
  8. 18 Apr, 2018 1 commit
  9. 15 Mar, 2018 1 commit
    • Beniamino Galvani's avatar
      dhcp: dhclient: set type 0 for printable client IDs · 8ffa22d1
      Beniamino Galvani authored
      The documentation for the ipv4.dhcp-client-id property says:
      
       If the property is not a hex string it is considered as a
       non-hardware-address client ID and the 'type' field is set to 0.
      
      However, currently we set the client-id without the leading zero byte
      in the dhclient configuration and thus dhclient sends the first string
      character as type and the remainder as client-id content. Looking
      through git history, the dhclient plugin has always behaved this way
      even if the intent was clearly that string client-id had to be zero
      padded (this is evident by looking at
      nm_dhcp_utils_client_id_string_to_bytes()). The internal plugin
      instead sends the correct client-id with zero type.
      
      Change the dhclient plugin to honor the documented behavior and add
      the leading zero byte when the client-id is a string.
      
      This commit introduces a change in behavior for users that have
      dhcp=dhclient and have a plain string (not hexadecimal) set in
      ipv4.dhcp-client-id, as NM will send a different client-id possibly
      changing the IP address returned by the server.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=793957
      8ffa22d1
  10. 07 Feb, 2018 1 commit
  11. 10 Nov, 2017 1 commit
  12. 03 Nov, 2017 1 commit
  13. 10 May, 2017 1 commit
  14. 20 Apr, 2017 1 commit
  15. 28 Mar, 2017 1 commit
  16. 23 Mar, 2017 1 commit
  17. 14 Feb, 2017 1 commit
  18. 25 Jan, 2017 1 commit
  19. 23 Jan, 2017 1 commit
  20. 17 Jan, 2017 1 commit
  21. 16 Dec, 2016 2 commits
  22. 15 Dec, 2016 1 commit
  23. 03 Nov, 2016 1 commit
  24. 12 Sep, 2016 1 commit
    • Thomas Haller's avatar
      device: change default value for cloned-mac-address to "preserve" (bgo#770611) · fae5ecec
      Thomas Haller authored
      Long ago before commit 1b49f941, NetworkManager did not touch the
      MAC address at all. Since 0.8.2 NetworkManager would modify the
      MAC address, and eventually it would reset the permanent MAC address
      of the device.
      
      This prevents a user from externally setting the MAC address via tools
      like macchanger and rely on NetworkManager not to reset it to the
      permanent MAC address. This is considered a security regression in
      bgo#708820.
      
      This only changed with commit 9a354cdc and 1.4.0. Since then it is possible
      to configure "cloned-mac-address=preserve", which instead uses the "initial"
      MAC address when the device activates.
      That also changed that the "initial" MAC address is the address which was
      externally configured on the device as last. In other words, the
      "initial" MAC address is picked up from external changes, unless it
      was NetworkManager itself who configured the address when activating a
      connection.
      
      However, in absence of an explicit configuration the default for
      "cloned-mac-address" is still "permanent". Meaning, the user has to
      explicitly configure that NetworkManager should not touch the MAC address.
      It makes sense to change the upstream default to "preserve". Although this
      is a change in behavior since 0.8.2, it seems a better default.
      
      This change has the drastic effect that all the existing connections
      out there with "cloned-mac-address=$(nil)" change behavior after upgrade.
      I think most users won't notice, because their devices have the permanent
      address set by default anyway. I would think that there are few users
      who intentionally configured "cloned-mac-address=" to have NetworkManager
      restore the permanent address.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=770611
      fae5ecec
  25. 02 Sep, 2016 1 commit
  26. 23 Aug, 2016 4 commits
  27. 17 Aug, 2016 1 commit
  28. 03 Aug, 2016 1 commit
  29. 19 May, 2016 1 commit
  30. 29 Mar, 2016 1 commit
  31. 16 Mar, 2016 1 commit
  32. 01 Mar, 2016 1 commit