1. 27 May, 2022 1 commit
  2. 19 May, 2022 1 commit
  3. 13 May, 2022 1 commit
  4. 03 May, 2022 5 commits
    • Thomas Haller's avatar
      NEWS: update · f3db8049
      Thomas Haller authored
      Resync latest changes from nm-1-38 branch.
      f3db8049
    • Thomas Haller's avatar
      NEWS: update · 202657c5
      Thomas Haller authored
      202657c5
    • Thomas Haller's avatar
      core: change the priority order in static "ipv6.addresses" · 257221d1
      Thomas Haller authored
      The order of addresses matters. For "ipv4.addresses", the list
      contains the primary address first. For "ipv6.addresses", the
      order was reverted. This was also documented behavior.
      
      The previous patch just changed behavior with respect to relative order
      of static IPv6 addresses and autoconf6/DHCPv6. As we seem in the mood
      for changing behavior, here is another one.
      
      Now the addresses are interpreted in an order consistent with IPv4 and
      how one might expect: preferred addresses first.
      
      (cherry picked from commit 3d6b6aa3)
      257221d1
    • Thomas Haller's avatar
      core: change order/priority of static IPv6 addresses relative to autoconf6/DHCPv6 · 171d70bb
      Thomas Haller authored
      The order of addresses can matter for source address selection.
      This is described in RFC 6724 section 5, but if the rules don't
      determine a clear winner, the order matters.
      
      Change the relative order of IPv6 addresses. Previously, we would prefer
      autoconf6, over DHCPv6, over manual addresses. Now that got reverted
      to make more sense and be consistent with IPv4.
      Also, if we had multiple autoconf6 addresses (received at different
      moments in time), then previously a newly received address would be
      added with highest priority. Now, the older address will be preferred
      and that order will be enforced (this can be a problem, see (*) below).
      
      For IPv4, it's all simple and sensible. When we add addresses in kernel
      via netlink, the first address (of a subnet) becomes the primary.
      Note that we only control the order of addresses of the same subnet.
      The addresses in ipv4.addresses" are sorted with primary address first.
      In the same way is the order for addresses in NML3ConfigData and for
      @known_addresses in nm_platform_ip_address_sync(), all primary-first.
      Also, manual addresses are sorted with higher priority compared to DHCPv4
      addresses (at least since NetworkManager 1.36). That means the way how we
      merge NML3ConfigData makes sense (nm_l3_config_data_merge()) because we first
      merge the static configuration, then the DHCPv4 configuration, where we just
      append the lower priority DHCPv4 addresses.
      
      For IPv6, the address priority is messed up. On netlink/kernel, the last added
      address becomes the preferred one (we thus need to add them in the order of
      lowest priority first). Consequently and historically, the IPv6 addresses in
      @known_addresses parameter to nm_platform_ip_address_sync() were
      lowest priority first. And so they were tracked in NML3ConfigData
      and in the profile ("ipv6.addresses"). That is confusing.
      Also, we usually want to merge NML3ConfigData with different priorities
      (e.g. static configuration from the profile before autoconf6/DHCPv6),
      as we do with IPv4. However, since internally IPv6 addresses are tracked in
      reverse order, it means later NML3ConfigData would be appended and get effectively
      a higher priority. That means, autoconf6 addresses were preferred over DHCPv6 and
      over manual "ipv6.addresses", respectively. That seems undesirable and inconsistent
      with IPv4. Change that. This is a change in behavior.
      
      Note that changing the order of addresses means to remove and re-add
      them in the right (inverse) order, with lease important first. This
      means, when we add a new address with lower priority, we need to remove
      all higher priority addresses temporarily, before readding them. That
      is a problem(*).
      
      Note that in the profile, "ipv6.addresses" is still tracked in reverse
      order. This did not change, but might change later.
      
      (cherry picked from commit 4a548423)
      171d70bb
    • Beniamino Galvani's avatar
      core: save DHCP lease information in state file in /run · 6ab5c4e5
      Beniamino Galvani authored
      DHCP leases for a given interface are already exported on D-Bus
      through DHCP4Config and DHCP6Config objects. It is useful to have the
      same information also available on the filesystem so that it can be
      easily used by scripts.
      
      NM already saves some information about DHCP leases in /var, however
      that directory can only be accessed by root, for good reasons.
      
      Append lease options to the existing state file
      /run/NetworkManager/devices/$ifindex. Contrary to /var this directory
      is not persistent, but it seems more correct to expose the lease only
      when it is active and not after it expired or after a reboot.
      
      Since the file is in keyfile format, we add new [dhcp4] and [dhcp6]
      sections; however, since some options have the same name for DHCPv4
      and DHCPv6, we add a "dhcp4." or "dhcp6." prefix to make the parsing
      by scripts (e.g. via "grep") easier.
      
      The option name is the same we use on D-Bus. Since some DHCPv6 options
      also have a "dhcp6_" prefix, the key na...
      6ab5c4e5
  5. 27 Apr, 2022 2 commits
    • Thomas Haller's avatar
      core: change the priority order in static "ipv6.addresses" · 3d6b6aa3
      Thomas Haller authored
      The order of addresses matters. For "ipv4.addresses", the list
      contains the primary address first. For "ipv6.addresses", the
      order was reverted. This was also documented behavior.
      
      The previous patch just changed behavior with respect to relative order
      of static IPv6 addresses and autoconf6/DHCPv6. As we seem in the mood
      for changing behavior, here is another one.
      
      Now the addresses are interpreted in an order consistent with IPv4 and
      how one might expect: preferred addresses first.
      3d6b6aa3
    • Thomas Haller's avatar
      core: change order/priority of static IPv6 addresses relative to autoconf6/DHCPv6 · 4a548423
      Thomas Haller authored
      The order of addresses can matter for source address selection.
      This is described in RFC 6724 section 5, but if the rules don't
      determine a clear winner, the order matters.
      
      Change the relative order of IPv6 addresses. Previously, we would prefer
      autoconf6, over DHCPv6, over manual addresses. Now that got reverted
      to make more sense and be consistent with IPv4.
      Also, if we had multiple autoconf6 addresses (received at different
      moments in time), then previously a newly received address would be
      added with highest priority. Now, the older address will be preferred
      and that order will be enforced (this can be a problem, see (*) below).
      
      For IPv4, it's all simple and sensible. When we add addresses in kernel
      via netlink, the first address (of a subnet) becomes the primary.
      Note that we only control the order of addresses of the same subnet.
      The addresses in ipv4.addresses" are sorted with primary address first.
      In the same way is the order for addresses in NML3ConfigData and for
      @known_addresses in nm_platform_ip_address_sync(), all primary-first.
      Also, manual addresses are sorted with higher priority compared to DHCPv4
      addresses (at least since NetworkManager 1.36). That means the way how we
      merge NML3ConfigData makes sense (nm_l3_config_data_merge()) because we first
      merge the static configuration, then the DHCPv4 configuration, where we just
      append the lower priority DHCPv4 addresses.
      
      For IPv6, the address priority is messed up. On netlink/kernel, the last added
      address becomes the preferred one (we thus need to add them in the order of
      lowest priority first). Consequently and historically, the IPv6 addresses in
      @known_addresses parameter to nm_platform_ip_address_sync() were
      lowest priority first. And so they were tracked in NML3ConfigData
      and in the profile ("ipv6.addresses"). That is confusing.
      Also, we usually want to merge NML3ConfigData with different priorities
      (e.g. static configuration from the profile before autoconf6/DHCPv6),
      as we do with IPv4. However, since internally IPv6 addresses are tracked in
      reverse order, it means later NML3ConfigData would be appended and get effectively
      a higher priority. That means, autoconf6 addresses were preferred over DHCPv6 and
      over manual "ipv6.addresses", respectively. That seems undesirable and inconsistent
      with IPv4. Change that. This is a change in behavior.
      
      Note that changing the order of addresses means to remove and re-add
      them in the right (inverse) order, with lease important first. This
      means, when we add a new address with lower priority, we need to remove
      all higher priority addresses temporarily, before readding them. That
      is a problem(*).
      
      Note that in the profile, "ipv6.addresses" is still tracked in reverse
      order. This did not change, but might change later.
      4a548423
  6. 19 Apr, 2022 1 commit
    • Lubomir Rintel's avatar
      nmcli: add --offline option for "add" and "modify" · 6fa1323c
      Lubomir Rintel authored
      This adds a global "--offline" option and allows its use with "add" and
      "modify" commands. The "add" looks like this:
      
        $ nmcli --offline conn add type ethernet ens3 ipv4.dns 192.168.1.1 \
            >output.nmconnection
      
      The "modify" is essentially implementing what's been suggested by
      Beniamino in bugzilla ticked (referred to below):
      
        $ nmcli --offline connection modify ens3 ipv4.dns 192.168.1.1 \
            <input.nmconnection >output.nmconnection
      
      Other commands don't support the argument at the moment:
      
        $ nmcli --offline c up ens3
        Error: 'up' command doesn't support --offline mode.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1361145
      6fa1323c
  7. 14 Apr, 2022 2 commits
    • Thomas Haller's avatar
      dhcp: drop internal systemd DHCPv4 client · 54119d41
      Thomas Haller authored
      This is long replaced by nettools' n-dhcp4 client.
      Drop it.
      
      We still require NMDhcpSystemd for the DHCPv6 client.
      
      Note that "[main].dhcp=systemd" now falls back to the internal client.
      But this option was undocumented and internal anyway.
      54119d41
    • Thomas Haller's avatar
      NEWS: update · 6ee8c8de
      Thomas Haller authored
      6ee8c8de
  8. 08 Apr, 2022 1 commit
  9. 07 Apr, 2022 2 commits
  10. 06 Apr, 2022 2 commits
  11. 24 Mar, 2022 1 commit
  12. 09 Mar, 2022 1 commit
  13. 06 Mar, 2022 1 commit
    • Beniamino Galvani's avatar
      core: fall back to loading all known settings plugins · 392daa5d
      Beniamino Galvani authored
      Currently it is possible to specify a list of default settings plugins
      to be used when configuration doesn't contain the main.plugins key.
      
      We want to add a mechanism that allows to automatically load any
      plugin found in the plugins directory without needing
      configuration. This mechanism is useful when plugins are shipped in a
      different, optional subpackage, to automatically use them.
      
      With such mechanism, the actual list of plugins will be determined
      (in order of evaluation):
      
       1. via explicit user configuration in /etc, if any
       2. via distro configuration in /usr, if any
       3. using the build-time default, if any
       4. looking for known plugins in /usr/lib
      392daa5d
  14. 24 Feb, 2022 2 commits
    • Thomas Haller's avatar
      NEWS: update · 38290b1b
      Thomas Haller authored
      This paragraph that "it's likely that" some changes will be backported
      to 1.34 branch seems unnecessary. Whenever we backport things to 1.34
      we will add them to the NEWS file for nm-1-34, and then also mention
      them in nm-1-36 and newer. But we don't need to announce that.
      38290b1b
    • Lubomir Rintel's avatar
      NEWS: update for 1.36.0 · dd563b3f
      Lubomir Rintel authored
      dd563b3f
  15. 23 Feb, 2022 1 commit
  16. 21 Feb, 2022 2 commits
  17. 16 Feb, 2022 1 commit
  18. 10 Feb, 2022 2 commits
  19. 04 Feb, 2022 1 commit
  20. 13 Jan, 2022 1 commit
  21. 11 Jan, 2022 2 commits
    • Beniamino Galvani's avatar
      nm-sudo: rename to nm-priv-helper · 6074ab1e
      Beniamino Galvani authored
      The name "nm-sudo" reminds of the "sudo" tool, and this is a bit
      confusing because it's not related. Rename the service to
      "nm-priv-helper", which stands for "NM privileged helper".
      
      !938
      (cherry picked from commit d68ab6b8)
      6074ab1e
    • Beniamino Galvani's avatar
      nm-sudo: rename to nm-priv-helper · d68ab6b8
      Beniamino Galvani authored
      The name "nm-sudo" reminds of the "sudo" tool, and this is a bit
      confusing because it's not related. Rename the service to
      "nm-priv-helper", which stands for "NM privileged helper".
      
      !938
      d68ab6b8
  22. 19 Nov, 2021 3 commits
  23. 18 Nov, 2021 2 commits
  24. 20 Oct, 2021 1 commit
  25. 17 Oct, 2021 1 commit