1. 18 Apr, 2019 1 commit
  2. 12 Apr, 2019 1 commit
  3. 11 Mar, 2019 1 commit
  4. 07 Mar, 2019 1 commit
  5. 23 Feb, 2019 1 commit
    • Thomas Haller's avatar
      build/meson: increase timeouts for some tests · b1f6d53b
      Thomas Haller authored
      The defaults for test timeouts in meson is 30 seconds. That is not long
      enough when running
        $ NMTST_USE_VALGRIND=1 ninja -C build test
      Note that meson supports --timeout-multiplier, and automatically
      increases the timeout when running under valgrind. However, meson
      does not understand that we are running tests under valgrind via
      NMTST_USE_VALGRIND=1 environment variable.
      Timeouts are really not expected to be reached and are a mean of last
      resort. Hence, increasing the timeout to a large value is likely to
      have no effect or to fix test failures where the timeout was too rigid.
      It's unlikely that the test indeed hangs and the increase of timeout
      causes a unnecessary increase of waittime before aborting.
  6. 21 Feb, 2019 1 commit
  7. 12 Feb, 2019 3 commits
  8. 08 Feb, 2019 2 commits
    • Thomas Haller's avatar
      tests: avoid "-Wmissing-braces" warning in test_nm_utils_dhcp_client_id_systemd_node_specific() · 4f931a19
      Thomas Haller authored
          [1/2] Compiling C object 'src/tests/a4ccf2d@@test-general@exe/test-general.c.o'.
          ../src/tests/test-general.c: In function ‘test_nm_utils_dhcp_client_id_systemd_node_specific’:
          ../src/tests/test-general.c:2056:16: warning: missing braces around initializer [-Wmissing-braces]
            } d_array[] = {
              .machine_id = { 0xcb, 0xc2, 0x2e, 0x47, 0x41, 0x8e, 0x40, 0x2a, 0xa7, 0xb3, 0x0d, 0xea, 0x92, 0x83, 0x94, 0xef },
    • Thomas Haller's avatar
      tests: avoid "-Wduplicate-decl-specifier" warning in test_duplicate_decl_specifier() · 2fe9ade1
      Thomas Haller authored
      The test should check the behavior with "const typeof(a)" in a macro,
      where "a" itself is const. For that we don't need a double const
      declaration of v2.
      Also, that fixes an actual compiler warning:
          ../src/tests/test-general.c: In function ‘test_duplicate_decl_specifier’:
          ../src/tests/test-general.c:1669:8: warning: duplicate ‘const’ declaration specifier [-Wduplicate-decl-specifier]
            const const int v2 = 3;
  9. 05 Feb, 2019 1 commit
    • Thomas Haller's avatar
      logging: make nm-logging thread-safe · fcfd4f4f
      Thomas Haller authored
      NetworkManager is single-threaded and uses a mainloop.
      However, sometimes we may need multiple threads. For example, we will
      need to write sysctl values asynchronously, using the glib thread-pool.
      For that to work, we also need to switch the network-namespace of the
      thread-pool thread. We want to use NMPNetns for that. Hence it's better
      to have NMPNetns thread-safe, instead of coming up with a duplicate
      implementation. But NMPNetns may want to log, so we also need nm-logging
      In general, code under "shared/nm-utils" and nm-logging should be usable
      from multiple threads. It's simpler to make this code thread-safe than
      re-implementing it. Also, it's a bad limitation to be unable to log
      from other threads. If there is an error, the best we can often do is to
      log about it.
      Make nm-logging thread-safe. Actually, we only need to be able to log
      from multiple threads. We don't need to setup or configure logging from
      multiple threads. This restriction allows us to access logging from the
      main-thread without any thread-synchronization (because all changes in
      the logging setup are also done from the main-thread).
      So, while logging from other threads requires a mutex, logging from the
      main-thread is lock-free.
  10. 15 Jan, 2019 1 commit
    • Thomas Haller's avatar
      tests: don't use alloca() in tests · e18ff51d
      Thomas Haller authored
      The only purpose of using alloca() to avoid the overhead of heap-allocation
      and possible save a line in source code for managing/freeing the heap allocation.
      For tests we don't care about performance, and (in this case)
      the code does not get any shorter.
      Avoid alloca() in tests, because alloca() is something to search for
      when reviewing code for stack overflows. No need to have such false
      positives show up in tests.
  11. 14 Jan, 2019 1 commit
  12. 02 Jan, 2019 2 commits
    • Thomas Haller's avatar
      systemd: expose unbase64mem() as nm_sd_utils_unbase64mem() · 0298d540
      Thomas Haller authored
      glib has an base64 implementation, but g_base64_decode() et al. gives
      no way to detect invalid encodings. All invalid codes are silently
      ignored. That is not suitable for strictly validating user input.
      Instead of reimplementing of copy-pasting the code from somewhere,
      reuse systemd's unbase64mem().
      But don't use "hexdecoct.h" directly. Instead, add a single accessor
      function to our "nm-sd-utils-shared.h" gateway. We want to be careful
      about which bits from systemd we use, because otherwise re-importing
      systemd code becomes fragile as you don't know which relevant parts
    • Thomas Haller's avatar
      systemd: move basic systemd library to shared/nm-utils · 2c537b9d
      Thomas Haller authored
      For better or worse, we already pull in large parts of systemd sources.
      I need a base64 decode implementation (because glib's g_base64_decode()
      cannot reject invalid encodings). Instead of coming up with my own or
      copy-paste if from somewhere, reuse systemd's unbase64mem().
      But for that, make systemd's basic bits an independent static library
      first because I will need it in libnm-core.
      This doesn't really change anything except making "libnm-systemd-core.la"
      an indpendent static library that could be used from "libnm-core". We
      shall still be mindful about which internal code of systemd we use, and only
      access functionality that is exposed via "systemd/nm-sd-utils-shared.h".
  13. 20 Dec, 2018 1 commit
  14. 11 Dec, 2018 3 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
      src/tests: add test for except match spec · d48904c9
      Thomas Haller authored
    • Thomas Haller's avatar
  15. 01 Dec, 2018 3 commits
  16. 29 Nov, 2018 1 commit
  17. 13 Nov, 2018 5 commits
    • Thomas Haller's avatar
      all: add "${MAC}" substituion for "connection.stable-id" · 7ffbf712
      Thomas Haller authored
      We already had "${DEVICE}" which uses the interface name.
      In times of predictable interface naming, that works well.
      It allows the user to generate IDs per device which don't
      change when the hardware is replaced.
      "${MAC}" is similar, except that is uses the permanent MAC
      address of the device. The substitution results in the empty
      word, if the device has no permanent MAC address (like software
      The per-device substitutions "${DEVICE}" and "${MAC}" are especially
      interesting with "connection.multi-connect=multiple".
    • Thomas Haller's avatar
      dhcp: reimplement node-specific DHCP client-id generation from systemd · a5579577
      Thomas Haller authored
      Our internal DHCP client (from systemd) defaults to a particular client ID.
      It is currently exposed as nm_sd_utils_generate_default_dhcp_client_id()
      and is based on the systemd implementation.
      One problem with that is, that it internally looks up the interface name
      with if_indextoname() and reads /etc/machine-id. Both makes it harder
      for testing.
      Another problem is, that this way of generating the client-id is
      currently limited to internal client. Why? If you use dhclient plugin,
      you may still want to use the same algorithm. Also, there is no explict
      "ipv4.dhcp-client-id" mode to select this client-id (so that it could
      be used in combination with "dhclient" plugin).
      As such, this code will be useful also aside systemd DHCP plugin.
      Hence, the function should not be obviously tied to systemd code.
      The implementation is simple enough, and since we already have a
      unit-test, refactor the code to our own implementation.
    • Thomas Haller's avatar
      dhcp: test systemd's default DHCP client identifier generation · 187d3561
      Thomas Haller authored
      Internal DHCP client generates a default client ID. For one,
      we should ensure that this algorithm does not change without
      us noticing, for example, when upgrading systemd code. Add
      a test, that the generation algorithm works as we expect.
      Also note, that the generation algorithm uses siphash24().
      That means, siphash24() implementation also must not change
      in the future, to ensure the client ID doesn't change. As we
      patch systemd sources to use shared/c-siphash, this is not
      obviously the case. Luckily c-siphash and systemd's siphash24 do
      agree, so all is good. The test is here to ensure that.
      Also, previously the generation algorithm is not exposed as a
      function, sd_dhcp_client will just generate a client-id when
      it needs it. However, later we want to know (and set) the client
      id before starting DHCP and not leave it unspecified to an
      implementation detail.
      This patch only adds a unit-test for the existing DHCP client
      ID generation to have something for comparison. In the next
      commit this will change further.
    • Thomas Haller's avatar
      core: don't persist secret-key for tests · 581e1c32
      Thomas Haller authored
      Tests might access the secret-key.
      For CI builds we may very well build NM as root and also run
      unit tests. In such a situation it's bad to persist the secret
      key. For example, the SELinux label may be wrong, and subsequently
      starting NetworkManager may cause errors. Avoid persisting the secret
      key for tests.
    • Thomas Haller's avatar
      core: refactor loading machine-id and cache it · 83083112
      Thomas Haller authored
      Previously, whenever we needed /etc/machine-id we would re-load it
      from file. The are 3 downsides of that:
       - the smallest downside is the runtime overhead of repeatedly
         reading the file and parse it.
       - as we read it multiple times, it may change anytime. Most
         code in NetworkManager does not expect or handle a change of
         the machine-id.
         Generally, the admin should make sure that the machine-id is properly
         initialized before NetworkManager starts, and not change it. As such,
         a change of the machine-id should never happen in practice.
         But if it would change, we would get odd behaviors. Note for example
         how generate_duid_from_machine_id() already cached the generated DUID
         and only read it once.
         It's better to pick the machine-id once, and rely to use the same
         one for the remainder of the program.
         If the admin wants to change the machine-id, NetworkManager must be
         restarted as well (in case the admin cares).
         Also, as we now only load it once, it makes sense to log an error
         (once) when we fail to read the machine-id.
       - previously, loading the machine-id could fail each time. And we
         have to somehow handle that error. It seems, the best thing what we
         anyway can do, is to log an error once and continue with a fake
         machine-id. Here we add a fake machine-id based on the secret-key
         or the boot-id. Now obtaining a machine-id can no longer fail
         and error handling is no longer necessary.
      Also, ensure that a machine-id of all zeros is not valid.
      Technically, a machine-id is not an RFC 4122 UUID. But it's
      the same size, so we also use NMUuid data structure for it.
      While at it, also refactor caching of the boot-id and the secret
      key. In particular, fix the thread-safety of the double-checked
      locking implementations.
  18. 12 Nov, 2018 3 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
      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.
  20. 23 Oct, 2018 3 commits
  21. 15 Sep, 2018 1 commit
  22. 07 Sep, 2018 2 commits
  23. 05 Sep, 2018 1 commit