1. 23 Dec, 2019 2 commits
  2. 18 Dec, 2019 1 commit
  3. 17 Dec, 2019 1 commit
  4. 13 Dec, 2019 1 commit
  5. 28 Nov, 2019 1 commit
  6. 22 Nov, 2019 2 commits
  7. 21 Nov, 2019 1 commit
  8. 20 Nov, 2019 2 commits
    • Thomas Haller's avatar
      dhcp/nettools: exactly calculate lease lifetimes · 0108d748
      Thomas Haller authored
      Now that we can not only get the expiry timestamp of the lease
      (n_dhcp4_client_lease_get_lifetime()), but also the base timestamp,
      we can calculate the lifetime exactly.
      Previously, we had to guess the base time by assuming that we just
      received the lease *now*. This wasn't exact.
    • Thomas Haller's avatar
      dhcp/nettools: don't trim the "expiry" timestamp to 32 bit · a8d46492
      Thomas Haller authored
      The "expiry" is the Unix timestamp when the lease expires.
      This is not at all a useful parameter, in particular because
      the system's clock can be reset. Instead, we should expose
      the lease receive time stamp (in CLOCK_BOOTTIME), and the lease
      Anyway. So, we somehow need to express infinite lifetimes. Previously,
      we would use the special value 4294967295 (2^32-1). However, that value
      does not seem so great, because it's also the Unix timestamp of
      2106-02-07T06:28:15+0000. While that is quite far in the future, it's
      a valid timestamp still. Of course, the code worked around that by never
      setting a timestamp larger than 4294967295-1, but it still limits the
      range of what we can expose.
      Note that for the lifetime "dhcp_lease_time", we do express infinity
      with 4294967295. That's fine, it also does not contradict what we
      receive in the DHCP lease on the wire because the lifetime there is
      expressed by a 32 bit integer.
      Instead, for the "expiry" timestamp, don't perform such triming.
      The expiry timestamp is just the start timestamp plus the lease
      lifetime. If that is larger than 2106-02-07, so be it.
      On the other hand, express infinity by omitting the "expiry" field.
  9. 18 Nov, 2019 1 commit
  10. 23 Oct, 2019 1 commit
    • Thomas Haller's avatar
      dhcp: truncate client-id for n-dhcp4 client at arbitrary limit · 7efc3c47
      Thomas Haller authored
      RFC does not define how long the client ID can be. However,
      n-dhcp4 enforces that the server replies with a client ID that
      matches the request. Also, the client ID gets encoded as a DHCP
      option, hence it cannot be longer than 255 bytes.
      While n-dhcp4 doesn't enforce a certain length, a too long client
      ID is not going to work. Hence, truncate it at 133 bytes.
      This is the same limit that also systemd's DHCP client has. It's chosen
      to fit an RFC4361-complient client ID with a DUID of length
      MAX_DUID_LEN (which is 128 bytes according to RFC 3315 section 9.1).
      Fixes-test: @ipv4_set_very_long_dhcp_client_id
      See-also: https://github.com/nettools/n-dhcp4/pull/6
  11. 02 Oct, 2019 1 commit
    • Thomas Haller's avatar
      all: unify format of our Copyright source code comments · 3b69f021
      Thomas Haller authored
      readarray -d '' FILES < <(
        git ls-files -z \
          ':(exclude)po' \
          ':(exclude)shared/c-rbtree' \
          ':(exclude)shared/c-list' \
          ':(exclude)shared/c-siphash' \
          ':(exclude)shared/c-stdaux' \
          ':(exclude)shared/n-acd' \
          ':(exclude)shared/n-dhcp4' \
          ':(exclude)src/systemd/src' \
          ':(exclude)shared/systemd/src' \
          ':(exclude)m4' \
      sed \
        -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[-–] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C1pyright#\5 - \7#\9/' \
        -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[,] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C2pyright#\5, \7#\9/' \
        -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C3pyright#\5#\7/' \
        -e 's/^Copyright \(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/C4pyright#\1#\3/' \
        -i \
      echo ">>> untouched Copyright lines"
      git grep Copyright "${FILES[@]}"
      echo ">>> Copyright lines with unusual extra"
      git grep '\<C[0-9]pyright#' "${FILES[@]}" | grep -i reserved
      sed \
        -e 's/\<C[0-9]pyright#\([^#]*\)#\(.*\)$/Copyright (C) \1 \2/' \
        -i \
  12. 23 Sep, 2019 1 commit
    • Thomas Haller's avatar
      dhcp/nettools: round time difference when calculating the lease lifetime · 87680c41
      Thomas Haller authored
      nettools does not expose the original lease lifetime. It's a missing
      API. Instead, it only exposes the timestamp when the lease will expire.
      As a workaround, we calulate the timestamp by subtracting the current
      timestamp from the expiration timestamp, assuming that the lease was
      received just now. However, it was not received *exactly* now, but a
      few milliseconds before. Hence, the calculated timestamp is not exact
      here and likely a few milliseconds less then the actual (full integer)
      Account for that by rounding the value to the second.
  13. 13 Sep, 2019 6 commits
  14. 10 Sep, 2019 1 commit
  15. 05 Sep, 2019 1 commit
    • Francesco Giudici's avatar
      dhcp: nettools: read/write lease files · 9f895169
      Francesco Giudici authored
      Use the same format of systemd-netword, so that we will be compatible
      with the leases created/read by the current "internal" plugin.
      Note that actually only the leased address is processed when reading a
      lease file, so no need to save more than the ip address when saving the
  16. 29 Aug, 2019 1 commit
  17. 13 Aug, 2019 2 commits
    • Thomas Haller's avatar
      dhcp: minor refactoring to switch default IPv4 DHCP plugin to "nettools" with one-line change · 75503c85
      Thomas Haller authored
      Minor refactoring so that there is only a one-line change necessary to
      flip the implementation of the "internal" DHCP plugin for IPv4 from
      "systemd" to "nettools".
      We don't do that yet, because there are still some issues (e.g. the
      lease is not persisted for nettools plugin). Eventually we want to
      switch, so prepare the code to be almost there.
    • Thomas Haller's avatar
      dhcp: make "systemd" DHCP plugin configurable · b53e2614
      Thomas Haller authored
      We have the "internal" DHCP plugin. That's our preferred plugin,
      and eventually we may drop all other plugins.
      Currently, the "internal" plugin is based on code from systemd-networkd
      and implemented in "src/dhcp/nm-dhcp-systemd.c". As this code is forked
      we eventually want to switch to nettools' n-dhcp4 library (for IPv4).
      For that reason we already have "src/dhcp/nm-dhcp-nettools.c".
      Note that "nettools" can be configured as a DHCP plugin, but this configuration
      is only experimental and for testing. There is never supposed to be a
      "nettools" plugin, but eventually the "internal" plugin will switch
      We don't want to replace systemd-based implementation right away. Not until
      we are sure that nettools works well. For that reason we keep them
      both in parallel for a while.
      This commit makes "systemd" DHCP plugin explicitly configurable
      in NetworkManager.conf. Like "nettools" this is an undocumented option,
      only for testing.
      If you choose "internal" (the default), you get one of the
      implementations (currently the "systemd" one). But by selecting
      "systemd" or "nettools" explicitly, you can select the exact plugin.
  18. 25 Jul, 2019 2 commits
  19. 05 Jul, 2019 6 commits
    • Beniamino Galvani's avatar
      dhcp: pass broadcast address to clients · 40babe1c
      Beniamino Galvani authored
      Read the broadcast address from platform and pass it to
      clients. Currently only the nettool backends uses it.
    • Beniamino Galvani's avatar
      dhcp: nettools: improve error messages · 36348c7d
      Beniamino Galvani authored
      Add the reason to error messages to make debugging easier.
      Note that n_dhcp4_client_new() also returns positive internal error
      values, so we can't use nm_utils_error_set_errno().
    • Beniamino Galvani's avatar
      dhcp: nettools: decrease initial delay · 7332c734
      Beniamino Galvani authored
      I think that artificially slowing down DHCP is not going to make users
      happier, so let's decrease it to the minimum allowed value (1 ms).
      Note that also dhclient and the internal client have it disabled. From
      the dhclient.conf man page:
       *initial-delay* parameter sets the maximum time client can wait after
       start before commencing first transmission.  According to RFC2131
       Section 4.4.1, client should wait a random time between startup and
       the actual first trans‐ mission. Previous versions of ISC DHCP client
       used to wait random time up to 5 seconds, but that was unwanted due
       to impact on startup time. As such, new versions have the default
       initial delay set to 0. To restore old behavior, please set
       initial-delay to 5.
    • Beniamino Galvani's avatar
      dhcp: nettools: support the FQDN option · 584298b7
      Beniamino Galvani authored
      Add option 81 (FQDN) when the ipv4.dhcp-fqdn property is set. We don't
      support changing the FQDN flags yet.
    • Beniamino Galvani's avatar
      dhcp: nettools: relicense as LGPL · 92a717e7
      Beniamino Galvani authored
      Acked-by: Tom Gundersen's avatarTom Gundersen <teg@jklm.no>
    • Tom Gundersen's avatar
      dhcp: add nettools dhcp4 client · 6adade6f
      Tom Gundersen authored
      This is inspired by the existing systemd integration, with a few differences:
      * This parses the WPAD option, which systemd requested, but did not use.
      * We hook into the DAD handling, only making use of the configured address
        once DAD has completed successfully, and declining the lease if it fails.
      There are still many areas of possible improvement. In particular, we need
      to ensure the parsing of all options are compliant, as n-dhcp4 treats all
      options as opaque, unlike sd-dhcp4. We probably also need to look at how
      to handle failures and retries (in particular if we decline a lease).
      We need to query the current MTU at client startu, as well as the hardware
      broadcast address. Both these are provided by the kernel over netlink, so
      it should simply be a matter of hooking that up with NM's netlink layer.
      Contribution under LGPL2.0+, in addition to stated licenses.