1. 03 May, 2022 12 commits
    • Lubomir Rintel's avatar
      platform: fix build · e04ff122
      Lubomir Rintel authored
        ./src/libnm-platform/nm-platform.h:1315: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        make[2]: *** [Makefile:11063: src/core/platform/tests/test-cleanup-fake] Error 1
        ./src/libnm-platform/nm-platform.h:1315: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        make[2]: *** [Makefile:11070: src/core/platform/tests/test-cleanup-linux] Error 1
      e04ff122
    • Lubomir Rintel's avatar
      test-ifcfg-rh: fix build · 6a909be0
      Lubomir Rintel authored
        src/core/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c:1449: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        make[2]: *** [Makefile:11132: src/core/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh] Error 1
      6a909be0
    • Lubomir Rintel's avatar
      fake-platform: fix build · 292003ef
      Lubomir Rintel authored
        src/core/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c:1449: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        make[2]: *** [Makefile:11132: src/core/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh] Error 1
        src/core/platform/nm-fake-platform.c:974: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        src/core/platform/nm-fake-platform.c:1145: undefined reference to `nm_utils_ip4_address_clear_host_address'
        /usr/bin/ld: src/core/platform/nm-fake-platform.c:1146: undefined reference to `nm_utils_ip4_address_clear_host_address'
        make[2]: *** [Makefile:11049: src/core/platform/tests/test-address-fake] Error 1
        src/core/platform/nm-fake-platform.c:974: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        src/core/platform/nm-fake-platform.c:1145: undefined reference to `nm_utils_ip4_address_clear_host_address'
        /usr/bin/ld: src/core/platform/nm-fake-platform.c:1146: undefined reference to `nm_utils_ip4_address_clear_host_address'
        make[2]: *** [Makefile:11063: src/core/platform/tests/test-cleanup-fake] Error 1
        src/core/platform/nm-fake-platform.c:974: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        src/core/platform/nm-fake-platform.c:1145: undefined reference to `nm_utils_ip4_address_clear_host_address'
        /usr/bin/ld: src/core/platform/nm-fake-platform.c:1146: undefined reference to `nm_utils_ip4_address_clear_host_address'
        make[2]: *** [Makefile:11077: src/core/platform/tests/test-link-fake] Error 1
        src/core/platform/nm-fake-platform.c:974: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        src/core/platform/nm-fake-platform.c:1145: undefined reference to `nm_utils_ip4_address_clear_host_address'
        /usr/bin/ld: src/core/platform/nm-fake-platform.c:1146: undefined reference to `nm_utils_ip4_address_clear_host_address'
        make[2]: *** [Makefile:11105: src/core/platform/tests/test-route-fake] Error 1
        src/core/platform/nm-fake-platform.c:974: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        src/core/platform/nm-fake-platform.c:1145: undefined reference to `nm_utils_ip4_address_clear_host_address'
        /usr/bin/ld: src/core/platform/nm-fake-platform.c:1146: undefined reference to `nm_utils_ip4_address_clear_host_address'
        make[2]: *** [Makefile:11028: src/core/ndisc/tests/test-ndisc-fake] Error 1
        src/core/platform/nm-fake-platform.c:974: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        src/core/platform/nm-fake-platform.c:1145: undefined reference to `nm_utils_ip4_address_clear_host_address'
        /usr/bin/ld: src/core/platform/nm-fake-platform.c:1146: undefined reference to `nm_utils_ip4_address_clear_host_address'
        make[2]: *** [Makefile:11187: src/core/tests/config/test-config] Error 1
      292003ef
    • Lubomir Rintel's avatar
      test-general: fix build · 894d022d
      Lubomir Rintel authored
        /usr/bin/ld: src/libnm-core-impl/tests/test_general-test-general.o: in function `test_ip4_netmask_to_prefix':
        src/libnm-core-impl/tests/test-general.c:4965: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        /usr/bin/ld: src/libnm-core-impl/tests/test-general.c:4966: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        /usr/bin/ld: src/libnm-core-impl/tests/test_general-test-general.o: in function `test_ip4_prefix_to_netmask':
        src/libnm-core-impl/tests/test-general.c:4937: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        collect2: error: ld returned 1 exit status
        make: *** [Makefile:11322: src/libnm-core-impl/tests/test-general] Error 1
      894d022d
    • Lubomir Rintel's avatar
      daemon: fix build · 6710d2a5
      Lubomir Rintel authored
        /usr/bin/ld: src/core/.libs/libNetworkManager.a(libNetworkManager_la-nm-dnsmasq-utils.o): in function `nm_dnsmasq_utils_get_range':
        src/core/dnsmasq/nm-dnsmasq-utils.c:53: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        /usr/bin/ld: src/core/.libs/libNetworkManager.a(libNetworkManager_la-nm-vpn-connection.o): in function `_dbus_signal_ip_config_cb':
        src/core/vpn/nm-vpn-connection.c:2109: undefined reference to `nm_utils_ip4_address_clear_host_address'
        collect2: error: ld returned 1 exit status
        make[2]: *** [Makefile:10920: src/core/NetworkManager-all-sym] Error 1
      6710d2a5
    • Lubomir Rintel's avatar
      nmtui: fix build · 28d3d654
      Lubomir Rintel authored
        /usr/bin/ld: src/nmtui/nmtui-nm-editor-bindings.o: in function `ip_route_transform_from_dest_string':
        src/nmtui/nm-editor-bindings.c:447: undefined reference to `_nm_utils_ip4_prefix_to_netmask'
        collect2: error: ld returned 1 exit status
        make[2]: *** [Makefile:11644: src/nmtui/nmtui] Error 1
      28d3d654
    • Lubomir Rintel's avatar
      cloud-setup: fix build · c36c604d
      Lubomir Rintel authored
        /usr/bin/ld: src/nm-cloud-setup/nm_cloud_setup-main.o: in function `_nmc_mangle_connection':
        src/nm-cloud-setup/main.c:369: undefined reference to `nm_utils_ip4_address_clear_host_address'
        /usr/bin/ld: src/nm-cloud-setup/main.c:360: undefined reference to `nm_utils_ip4_address_clear_host_address'
        collect2: error: ld returned 1 exit status
        make: *** [Makefile:11403: src/nm-cloud-setup/nm-cloud-setup] Error 1
      c36c604d
    • Beniamino Galvani's avatar
      ee724078
    • 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 name can contain "dhcp6" twice.
      
      The new sections look like this:
      
        [dhcp4]
        dhcp4.broadcast_address=172.25.1.255
        dhcp4.dhcp_lease_time=120
        dhcp4.dhcp_server_identifier=172.25.1.4
        dhcp4.domain_name_servers=172.25.1.4
        dhcp4.domain_search=example.com
        dhcp4.expiry=1641214444
        dhcp4.ip_address=172.25.1.182
        dhcp4.next_server=172.25.1.4
        dhcp4.routers=172.25.1.4
        dhcp4.subnet_mask=255.255.255.0
      
        [dhcp6]
        dhcp6.dhcp6_name_servers=fd01::1
        dhcp6.dhcp6_ntp_servers=ntp.example.com
        dhcp6.ip6_address=fd01::1aa
      6ab5c4e5
    • Beniamino Galvani's avatar
      core: add nm_dhcp_config_get_option_values() · 96d8637c
      Beniamino Galvani authored
      Introduce a function to return an array of name-value tuples for DHCP
      options.
      96d8637c
    • Beniamino Galvani's avatar
      dhcp: fix logging domain · 15a42113
      Beniamino Galvani authored
      Fix wrong domain when logging a lease:
      
        dhcp6 (veth0):   valid_lft 7200
        dhcp6 (veth0):   preferred_lft 5400
        dhcp6 (veth0):   address fd00:db8:db8::11:2233:4455
        dhcp (veth0):   domain search 'domain'
      15a42113
    • Beniamino Galvani's avatar
      dhcp: improve logging for DHCPv6 merged leases · f20ac6bd
      Beniamino Galvani authored
      Instead of logging the event-id, which is composed from options that
      are already visible in the log, it's more interesting to log that the
      lease was merged.
      f20ac6bd
  2. 02 May, 2022 4 commits
    • Thomas Haller's avatar
      build/meson: avoid compiler warning generating "NM-1.0.gir" · e5d41946
      Thomas Haller authored
      In glib_dep we specify
      
        "-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40"
      
      which is the dependency we use almost everywhere. With g-ir-scanner
      this causes compiler warnings:
      
          [xxx] Generating NM-1.0.gir with a custom command
          /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c: In function ‘dump_object_type’:
          /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c:252:13: warning: Not available before 2.70
            252 |   if (G_TYPE_IS_FINAL (type))
                |             ^~~~~~~~~~~~~~~~~
          /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c: In function ‘dump_fundamental_type’:
          /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c:370:13: warning: Not available before 2.70
            370 |   if (G_TYPE_IS_FINAL (type))
                |             ^~~~~~~~~~~~~~~~~
          g-ir-scanner: link: gcc -o /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0 /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -L/src/NetworkManager/build/src/libnm-client-impl -Wl,-rpath,/src/NetworkManager/build/src/libnm-client-impl -lnm -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgmodule-2.0 -ludev -lgirepository-1.0 -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lglib-2.0
      
      Work around that.
      
      Meson's gnome.generate_gir() is not very flexibly in allowing to
      pass extra `--cflags-begin {} --cflags-end` parameters.
      Hack around by adding a pseudo dependency that resets
      these defines.
      
      See-also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/331
      See-also: 1234e558 ('build/autotools: avoid compiler warning generating "NM-1.0.gir"')
      e5d41946
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      examples: improve finding last checkpoint in "checkpoint.py" · 3ce3ed4c
      Thomas Haller authored
      This is a python example. We should do nice things, like
      using max() for finding the maximum, instead of sorting.
      3ce3ed4c
    • Thomas Haller's avatar
      core: transfer ownership of strbuf data in _fw_nft_set() · 6a04bcc5
      Thomas Haller authored
      In practice there is little difference.
      
      Previously, "strbuf" would own the string until the end of the function,
      when the "nm_auto_str_buf" cleanup attribute destroys it. In the
      meantime, we would pass it on to _fw_nft_call_sync(), which in fact
      won't access the string after returning.
      
      Instead, we can just transfer ownership to the GBytes instance. That seems
      more logical and safer than aliasing the buffer owned by NMStrBuf with
      a g_bytes_new_static(). That way, we don't add a non-obvious restriction
      on the lifetime of the string. The lifetime is now guarded by the GBytes
      instance, which, could be referenced and kept alive longer.
      
      There is also no runtime/memory overhead in doing this.
      6a04bcc5
  3. 01 May, 2022 1 commit
  4. 28 Apr, 2022 5 commits
  5. 27 Apr, 2022 4 commits
    • Thomas Haller's avatar
    • 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
    • Thomas Haller's avatar
      device: set MTU after attaching bond port · 6804c2ba
      Thomas Haller authored
      When attaching a bond port, kernel will reset the MTU of the port ([1],
      [2]). Configuring a different MTU on the port seems not a sensible
      thing for the user to do.
      
      Still, before commit e67ddd82 ('device: commit MTU during stage2')
      we would first attach the bond port before setting the MTU. That
      changed, and now the MTU set by kernel wins.
      
      Btw, this change in behavior happens because we attach the port in
      stage3 (ip-config), which seems an ugly thing to do.
      
      Anyway, fix this by setting the MTU after attaching the ports, but still
      in stage3.
      
      It is probably not sensible for the user to configure a different MTU.
      Still, if the user requested it by configuration, we should apply it.
      Note that NetworkManager has some logic to constrain the MTU based on
      the parent/child and controller/port. In many regards however, NetworkManager
      does not fully understand or enforce the correct MTU and relies on the
      user to configure it correctly. After all, if the user misconfigures the
      MTU, the setup will have problems anyway (and in many cases neither
      kernel nor NetworkManager could know that the configuration is wrong).
      
      [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/bonding/bond_main.c?h=v5.17#n3603
      [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/bonding/bond_main.c?h=v5.17#n4372
      
      https://bugzilla.redhat.com/show_bug.cgi?id=2071985
      
      Fixes: e67ddd82 ('device: commit MTU during stage2')
      
      !1199
      6804c2ba
  6. 26 Apr, 2022 2 commits
    • Thomas Haller's avatar
      all: hardcode HOST_NAME_MAX to 64 · 7fcfc5cc
      Thomas Haller authored
      On glibc, HOST_NAME_MAX is defined as 64. Also, Linux'
      sethostname() enforces that limit (__NEW_UTS_LEN). Also,
      `man gethostname` comments that HOST_NAME_MAX on Linux is
      64.
      
      However, when building against musl, HOST_NAME_MAX is defined as 255.
      That seems wrong. We use this limit to validate the hostname, and that
      should not depend on the libc or on the compilation.
      
      Hardcode the value to 64.
      
      !1197
      7fcfc5cc
    • Yuri Chornoivan's avatar
      po: update Ukrainian (uk) translation · da7dbc03
      Yuri Chornoivan authored and Thomas Haller's avatar Thomas Haller committed
      !1198
      da7dbc03
  7. 21 Apr, 2022 2 commits
    • Thomas Haller's avatar
      clients/tests: declare encoding of utf-8 python source "test-client.py" · 26a0307b
      Thomas Haller authored
      The source file now contains UTF-8 (non ASCII) characters. Python2
      doesn't like that:
      
        "./src/tests/client/test-client.sh" "." "." "/usr/bin/python"
          File "/builddir/build/BUILD/NetworkManager-1.39.2/src/tests/client/test-client.py", line 1730
        SyntaxError: Non-ASCII character '\xe2' in file /builddir/build/BUILD/NetworkManager-1.39.2/src/tests/client/test-client.py on line 1730, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
      26a0307b
    • Lubomir Rintel's avatar
      configure.ac: fix a syntax error · a8284b1d
      Lubomir Rintel authored
      Fixes this error:
      
        checking whether more special flags are required for pthreads... no
        checking for PTHREAD_PRIO_INHERIT... yes
        ./configure: line 30294: ,as_fn_error: command not found
        checking for a Python interpreter with version >= 3... python
        checking for python... /usr/bin/python
      
      Fixes: 3affccf2 ('tests: fix undefined references to pthread')
      a8284b1d
  8. 20 Apr, 2022 10 commits