1. 12 Feb, 2019 2 commits
  2. 19 Nov, 2018 1 commit
  3. 14 Nov, 2018 1 commit
    • Thomas Haller's avatar
      dhcp: initialize hostname as construct-property · 787f4b57
      Thomas Haller authored
      The hostname property is only initialized once, early on during
      start. Move the initialization even earlier during object constructions.
      This effectively makes the hostname an immutable property.
      This also makes sense, because the hostname is used by IPv4 and
      IPv6 DHCP instances alike.
  4. 13 Nov, 2018 5 commits
    • Thomas Haller's avatar
      dhcp: cleanup initializing IPv4 client-id for internal DHCP · c3e7e617
      Thomas Haller authored
      - if we leave the client-id of sd_dhcp_client unset, it will
        anyway generate a node-specific client-id (and may fail if
        "/etc/machine-id" is invalid).
        Anticipate that, and don't let the client-id unset. In case
        we have no client-id from configuration or lease, just generate
        the id ourself (using the same algorithm). The advantage is,
        that we know it upfront and can store the client-id in the
        NMDhcpClient instance. We no longer need to peel it out from
        the lease later.
      - to generate the IPv4 client-id, we need a valid MAC address. Also,
        sd_dhcp_client needs a MAC address for dhcp_network_bind_raw_socket()
        as well. Just require that a MAC address is always needed. Likewise,
        we need a valid ifindex and ifname set.
      - likewise for IPv6 and IPv4, cleanup detecting the arptype and
        checking MAC address length. sd_dhcp_client_set_mac() is overly
        strict at asserting input arguments, so we must validate them anyway.
      - also, now that we always initialize the client-id when starting
        the DHCP client, there is no need to retroactively extract it
        again when we receive the first lease.
    • Thomas Haller's avatar
      dhcp: don't pass duid to client ip6_start() and stop() · 7d55b134
      Thomas Haller authored
      We don't do that for ip4_start() either. The duid/client-id
      is stored inside the NMDhcpClient instance, and the function can
      access it from there.
      Maybe, it is often preferable to have stateless objects and not
      relying on ip4_start() to obtain the client ID from the client's
      state. However, the purpose of the NMDhcpClient object is to
      hold state about DHCP. To simplify the complexity of objects that
      inherrently have state, we should be careful about mutating the state.
      It adds little additional complexity of only reading the state when
      needed anyway. In fact, it adds complexity, because previously
      it wasn't enough to check all callers of nm_dhcp_client_get_client_id()
      to see where the client-id is used. Instead, one would also need to
      follow the @duid argument several layers of the call stack.
    • Thomas Haller's avatar
      dhcp: merge "duid" and "client_id" field in NMDhcpClient · 7e341b73
      Thomas Haller authored
      We only used "client_id" for IPv4 and "duid" for IPv6. Merge them.
      Another advantage is, that we can share the logging functionality
      of _set_client_id().
    • Thomas Haller's avatar
      dhcp: don't re-read DHCP client ID from configuration file for dhclient · 5411fb0c
      Thomas Haller authored
      Why would we do this? The configuration file we are reading back was
      written by NetworkManager in the first place.
      Maybe when assuming a connection after restart, this information could
      be interesting. It however is not actually relevant.
      Note how nm_dhcp_client_get_client_id() has only very few callers.
        - nm_device_spawn_iface_helper() in 'nm-device.c'. In this case,
          we either should use the client-id which we used when starting
          DHCP, or none at all.
        - ip4_start() in 'nm-dhcp-dhclient.c', but this is before starting
          DHCP client and before it was re-read from configuration file.
        - in "src/dhcp/nm-dhcp-systemd.c", but this has no effect for
          the dhclient plugin.
    • 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.
  5. 18 Oct, 2018 1 commit
  6. 15 Oct, 2018 1 commit
    • Beniamino Galvani's avatar
      dhcp: introduce terminated dhcp-state · 0a25b908
      Beniamino Galvani authored
      When the client terminates, we really don't care if it exited cleanly,
      with an error or killed by a signal. We expect the client to never
      exit and so all these situations are equally bad for us. Introduce a
      new TERMINATED state instead of reusing existing FAIL or DONE states,
      which are set when receiving particular events from the client.
  7. 12 Sep, 2018 2 commits
  8. 08 Aug, 2018 1 commit
  9. 11 Jul, 2018 1 commit
    • Thomas Haller's avatar
      all: don't use gchar/gshort/gint/glong but C types · e1c7a2b5
      Thomas Haller authored
      We commonly don't use the glib typedefs for char/short/int/long,
      but their C types directly.
          $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
      One could argue that using the glib typedefs is preferable in
      public API (of our glib based libnm library) or where it clearly
      is related to glib, like during
        g_object_set (obj, PROPERTY, (gint) value, NULL);
      However, that argument does not seem strong, because in practice we don't
      follow that argument today, and seldomly use the glib typedefs.
      Also, the style guide for this would be hard to formalize, because
      "using them where clearly related to a glib" is a very loose suggestion.
      Also note that glib typedefs will always just be typedefs of the
      underlying C types. There is no danger of glib changing the meaning
      of these typedefs (because that would be a major API break of glib).
      A simple style guide is instead: don't use these typedefs.
      No manual actions, I only ran the bash script:
        FILES=($(git ls-files '*.[hc]'))
        sed -i \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>  /\1   /g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
  10. 20 Jun, 2018 4 commits
  11. 09 Jun, 2018 2 commits
    • Francesco Giudici's avatar
      dhcp: allow to skip DUID search from DHCP client global configuration · f054c3fc
      Francesco Giudici authored
      When the used client is dhclient we were used to search for DUID not
      only in the specific lease files generated by NetworkManager, but also
      in the global lease file generated outside NetworkManager.
      Keep this capability but allow to just search in the NM lease files if
      a value different from the default one is specified in dhcp-duid.
    • Francesco Giudici's avatar
      dhcp: remove fallback DUID-UUID generation from dhcp code · 0d841e74
      Francesco Giudici authored
      This commit centralizes the DUID generation in nm-device.c.
      As a consequence, a DUID is always provided when starting a
      DHCPv6 client. The DHCP client can override the passed DUID
      with the value contained in the client-specific lease file.
  12. 08 Jun, 2018 1 commit
    • Francesco Giudici's avatar
      libnm-core: add ipv6.dhcp-duid property · 7a0b6b17
      Francesco Giudici authored
      allow to specify the DUID to be used int the DHCPv6 client identifier
      option: the dhcp-duid property accepts either a hex string or the
      special values "lease", "llt", "ll", "stable-llt", "stable-ll" and
      "lease": give priority to the DUID available in the lease file if any,
               otherwise fallback to a global default dependant on the dhcp
               client used. This is the default and reflects how the DUID
               was managed previously.
      "ll": enforce generation and use of LL type DUID based on the current
            hardware address.
      "llt": enforce generation and use of LLT type DUID based on the current
             hardware address and a stable time field.
      "stable-ll": enforce generation and use of LL type DUID based on a
                   link layer address derived from the stable id.
      "stable-llt": enforce generation and use of LLT type DUID based on
                    a link layer address and a timestamp both derived from the
                    stable id.
      "stable-uuid": enforce generation and use of a UUID type DUID based on a
                     uuid generated from the stable id.
  13. 07 Jun, 2018 1 commit
  14. 26 May, 2018 3 commits
  15. 16 May, 2018 1 commit
  16. 10 May, 2018 1 commit
    • Lubomir Rintel's avatar
      all: use the elvis operator wherever possible · e69d3869
      Lubomir Rintel authored
        expression a, b;
        -a ? a : b
        +a ?: b
      Applied with:
        spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir .
      With some manual adjustments on spots that Cocci didn't catch for
      reasons unknown.
      Thanks to the marvelous effort of the GNU compiler developer we can now
      spare a couple of bits that could be used for more important things,
      like this commit message. Standards commitees yet have to catch up.
  17. 15 Feb, 2018 5 commits
    • Thomas Haller's avatar
      dhcp: inject client-id in GBytes format from NMDevice to nm_dhcp_manager_start_ip4() · 7de078a3
      Thomas Haller authored
      Convert the string representation of ipv4.dhcp-client-id property already in
      NMDevice to a GBytes. Next, we will support more client ID modes, and we
      will need the NMDevice context to generate the client id.
    • Thomas Haller's avatar
      dhcp: refactor type of NMDhcpClient duid to be GBytes · 578c4af9
      Thomas Haller authored
      GBytes is immutable. It's better suited to contain the duid parameter
      then a GByteArray.
    • Thomas Haller's avatar
      dhcp: refactor type of NMDhcpClient hwaddr to be GBytes · b0e98561
      Thomas Haller authored
      GByteArray is a mutable array of bytes. For every practical purpose, the hwaddr
      property of NMDhcpClient is an immutable sequence of bytes. Thus, make it a
    • Thomas Haller's avatar
      dhcp: initialize use_fqdn and info_only paramters in constructor · 167a1d5f
      Thomas Haller authored
      The two boolean properties do not need to be ever reset. It's nice
      to initialize such properties in the constructor and don't mutate
      them afterwards.
      Instead of adding two boolean GObject properties, add a new flags property
      that can encode these two values. In the end, properties are too
      cumbersome, let's combine them.
    • Thomas Haller's avatar
      dhcp: cache info-only parameter in NMDhcpClient · 8ff962d9
      Thomas Haller authored
      Optimally, NMDhcpClient would be stateless and all paramters would
      be passed on as argument. Clearly that is not feasable, because there
      are so many paramters, and in many cases they need to be cached for the
      lifetime of the client instance.
      Instead of passing info_only paramter to ip6_start() and cache it
      both in NMDhcpClient and NMDhcpSystemd, keep it in NMDhcpClient at
      one place.
      In the next commit, we will initialize info-only only once during the
      constructor, so it is immutable and somewhat stateless.
  18. 09 Jan, 2018 1 commit
  19. 04 Jan, 2018 2 commits
    • Thomas Haller's avatar
      dhcp: cleanup handling of ipv4.dhcp-client-id and avoid assertion failure · 686afe53
      Thomas Haller authored
      The internal client asserts that the length of the client ID is not more
      than MAX_CLIENT_ID_LEN. Avoid that assert by truncating the string.
      Also add new nm_dhcp_client_set_client_id_*() setters, that either
      set the ID based on a string (in our common dhclient specific
      format), or based on the binary data (as obtained from systemd client).
      Also, add checks and assertions that the client ID which is
      set via nm_dhcp_client_set_client_id() is always of length
      of at least 2 (as required by rfc2132, section-9.14).
    • Thomas Haller's avatar
      dhcp: track dhcp-client instances with CList instead of hash-table · c19f6359
      Thomas Haller authored
      NMDhcpManager used a hash table to keep track of the dhcp client
      instances. It never actually did a lookup of the client, the only
      place where we search for an existing NMDhcpClient instance is
      get_client_for_ifindex(), which just iterated over all clients.
      Use a CList instead.
      The only thing that one might consider a downside is that now
      NMDhcpClient is aware of whether it is part of a list. Previously,
      one could theoretically track a NMDhcpClient instance in multiple
      NMDhcpManager instances. But that doesn't make sense, because
      NMDhcpManager is a singleton. Even if we would have mulitple NMDhcpManager
      instances, one client would still only be tracked by one manager.
      This tighter coupling of NMDhcpClient and NMDhcpManager isn't
      a problem.
  20. 18 Dec, 2017 1 commit
  21. 18 Oct, 2017 1 commit
    • Thomas Haller's avatar
      core,clients: use our own string hashing function nm_str_hash() · 34342618
      Thomas Haller authored
      Replace the usage of g_str_hash() with our own nm_str_hash().
      GLib's g_str_hash() uses djb2 hashing function, just like we
      do at the moment. The only difference is, that we use a diffrent
      seed value.
      Note, that we initialize the hash seed with random data (by calling
      getrandom() or reading /dev/urandom). That is a change compared to
      This change of the hashing function and accessing the random pool
      might be undesired for libnm/libnm-core. Hence, the change is not
      done there as it possibly changes behavior for public API. Maybe
      we should do that later though.
      At this point, there isn't much of a change. This patch becomes
      interesting, if we decide to use a different hashing algorithm.
  22. 17 Oct, 2017 1 commit
    • Thomas Haller's avatar
      shared: split random and hash utils · 281d2d9f
      Thomas Haller authored
      "nm-utils/nm-shared-utils.h" shall contain utility function without other
      dependencies. It is intended to be used by other projects as-is.
      nm_utils_random_bytes() requires getrandom() and a HAVE_GETRANDOM configure
      check. That makes it more cumbersome to re-use "nm-shared-utils.h", in
      cases where you don't care about nm_utils_random_bytes().
      Split nm_utils_random_bytes() out to a separate file.
      Same for hash utils, which depend on nm_utils_random_bytes(). Also, hash
      utils will eventually be extended to use siphash24.
  23. 13 Oct, 2017 1 commit