1. 11 Jun, 2019 2 commits
    • Thomas Haller's avatar
      all: drop empty first line from sources · 87a73df9
      Thomas Haller authored
        git ls-files -z -- ':(exclude)src/settings/plugins/keyfile/tests/keyfiles' | xargs -0 -n1 sed -i '1 { /^$/d }'
    • Thomas Haller's avatar
      all: drop emacs file variables from source files · c0e075c9
      Thomas Haller authored
      We no longer add these. If you use Emacs, configure it yourself.
      Also, due to our "smart-tab" usage the editor anyway does a subpar
      job handling our tabs. However, on the upside every user can choose
      whatever tab-width he/she prefers. If "smart-tabs" are used properly
      (like we do), every tab-width will work.
      No manual changes, just ran commands:
          F=($(git grep -l -e '-\*-'))
          sed '1 { /\/\* *-\*-  *[mM]ode.*\*\/$/d }'     -i "${F[@]}"
          sed '1,4 { /^\(#\|--\|dnl\) *-\*- [mM]ode/d }' -i "${F[@]}"
      Check remaining lines with:
          git grep -e '-\*-'
      The ultimate purpose of this is to cleanup our files and eventually use
      SPDX license identifiers. For that, first get rid of the boilerplate lines.
  2. 01 May, 2019 1 commit
    • Thomas Haller's avatar
      libnm: unify property-to-dbus handling of NMSetting · 0d1b8ee9
      Thomas Haller authored
      Merge the function pointer get_func() into to_dbus_fcn().
      Previously, get_func() as handled separately from to_dbus_fnc()
      (formerly synth_func()). The notion was that synth-func would syntetize
      properties that are D-Bus only. But that distinction does not seem
      very helpful to me.
      Instaed, we want to convert a property to D-Bus. Period. The
      implementation should be handled uniformly. Hence, now that is
      all done by property_to_dbus().
      Note that property_to_dbus() is also called as default implementation
      for compare-property. At least, for properties that are backed by a
      GObject property.
  3. 12 Feb, 2019 1 commit
  4. 15 Jan, 2019 2 commits
    • Thomas Haller's avatar
      libnm-core: reorder code in settings · 19141ef7
      Thomas Haller authored
      Order the code in our common way. No other changes.
      - ensure to include the main header first (directly after
      - reorder function definitions: get_property(), set_property(),
        *_init(), *_new(), finalize(), *_class_init().
    • Thomas Haller's avatar
      libnm-core: cleanup NMSetting's class initialization · a3d6976e
      Thomas Haller authored
      Unify the coding style for class-init functions in libnm-core.
      Also make use of obj_properties, NM_GOBJECT_PROPERTIES_DEFINE(), and
  5. 07 Jan, 2019 1 commit
    • Thomas Haller's avatar
      libnm: pass serialization flags to settings synth_func() · e8bf89a9
      Thomas Haller authored
      We will need access to the serialization flags from within the synth_func().
      That will be for WireGuard's peers. Peers are a list of complex, structured
      elements, and some fields (the peer's preshared-key) are secret and
      others are not. So when serializing the peers, we need to know whether
      to include secrets or not.
      Instead of letting _nm_setting_to_dbus() check the flags, pass them
      While at it, don't pass the property_name argument. Instead, pass the
      entire meta-data information we have. Most synth functions don't care
      about the property or the name either way. But we should not pre-filter
      information that we have at hand. Just pass it to the synth function.
      If the synth function would be public API, that would be a reason to be
      careful about what we pass. But it isn't and it only has one caller.
      So passing it along is fine. Also, do it now when adding the flags
      argument, as we touch all synth implementations anyway.
  6. 10 Dec, 2018 1 commit
  7. 13 Nov, 2018 3 commits
    • Thomas Haller's avatar
      dhcp: add "ipv4.dhcp-client-id=duid" setting · 8861ac29
      Thomas Haller authored
      Add a new mode for the DHCPv4 client identifier.
      "duid" is what the internal (systemd) DHCP client already does by
      default. It is also the same as used by systemd-networkd's
      "ClientIdentifier=duid" setting. What we still lack (compared to
      networkd) are a way to overwrite IAID and the DUID.
      Previously, this mode was used by the internal DHCP plugin
      by default. However, it could not be explicitly configured.
      In general, our default values should also be explicitly selectable.
      Now the "duid" client identifier can also be used with the "dhclient"
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      dhcp: don't load IPv4 client-id from lease file · 5b9bc174
      Thomas Haller authored
      The client-id is something that we want to determine top-down.
      Meaning, if the user specifies it via ipv4.dhcp-client-id, then it
      should be used. If the user leaves it unspecified, we choose a
      default stable client-id. For the internal DHCP plugin, this is
      a node specific client-id based on
        - the predictable interface name
        - and /etc/machine-id
      It's not clear, why we should allow specifying the client-id in
      the lease file as a third source of configuration. It really pushes
      the configuration first down (when we do DHCP without lease file),
      to store an additional bit of configuration for future DHCP attempts.
      If the machine-id or the interface-name changes, then so does the
      default client-id. In this case, also "ipv4.dhcp-client-id=stable"
      changes. It's fair to require that the user keeps the machine-id
      stable, if the machine identity doesn't change.
      Also, the lease files are stored in /var/lib/NetworkManager, which
      is more volatile than /etc/machine-id. So, if we think that machine-id
      and interface-name is not stable, why would we assume that we have
      a suitable lease file?
      Also, if you do:
         nmcli connection add con-name "$PROFILE" ... ipv4.dhcp-client-id ''
         nmcli connection up $PROFILE
         nmcli connection modify "$PROFILE" ipv4.dhcp-client-id mac
         nmcli connection up $PROFILE
         nmcli connection modify "$PROFILE" ipv4.dhcp-client-id ''
         nmcli connection up $PROFILE
      wouldn't you expect that the original (default) client-id is used again?
      Also, this works badly with global connection defaults in
      NetworkManager.conf. If you configure a connection default, previously
      already this would always force the client-id and overrule the lease.
      That is reasonable, but in which case would you ever want to use
      the client-id from the lease?
  8. 19 Aug, 2018 1 commit
  9. 10 Aug, 2018 3 commits
    • Thomas Haller's avatar
      libnm: rework setting metadata for property handling · 37938043
      Thomas Haller authored
      NMSetting internally already tracked a list of all proper GObject properties
      and D-Bus-only properties.
      Rework the tracking of the list, so that:
      - instead of attaching the data to the GType of the setting via
        g_type_set_qdata(), it is tracked in a static array indexed by
        NMMetaSettingType. This allows to find the setting-data by simple
        pointer arithmetic, instead of taking a look and iterating (like
        g_type_set_qdata() does).
        Note, that this is still thread safe, because the static table entry is
        initialized in the class-init function with _nm_setting_class_commit().
        And it only accessed by following a NMSettingClass instance, thus
        the class constructor already ran (maybe not for all setting classes,
        but for the particular one that we look up).
        I think this makes initialization of the metadata simpler to
        Previously, in a first phase each class would attach the metadata
        to the GType as setting_property_overrides_quark(). Then during
        nm_setting_class_ensure_properties() it would merge them and
        set as setting_properties_quark(). Now, during the first phase,
        we only incrementally build a properties_override GArray, which
        we finally hand over during nm_setting_class_commit().
      - sort the property infos by name and do binary search.
      Also expose this meta data types as internal API in nm-setting-private.h.
      While not accessed yet, it can prove beneficial, to have direct (internal)
      access to these structures.
      Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
      naming scheme. We already have 40+ subclasses of NMSetting that are called
      NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
      new, distinct name.
    • Thomas Haller's avatar
      libnm: use NMMetaSettingInfo for tracking setting priority · 9c47e2ce
      Thomas Haller authored
      Previously, each (non abstract) NMSetting class had to register
      its name and priority via _nm_register_setting().
      Note, that libnm-core.la already links against "nm-meta-setting.c",
      which also redundantly keeps track of the settings name and gtype
      as well.
      Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta
      The goal is to get rid of private data structures that track
      meta data about NMSetting classes. In this case, "registered_settings"
      hash. Instead, we should have one place where all this meta data
      is tracked. This was, it is also accessible as internal API,
      which can be useful (for keyfile).
      Note that NMSettingClass has some overlap with NMMetaSettingInfo.
      One difference is, that NMMetaSettingInfo is const, while NMSettingClass
      is only initialized during the class_init() method. Appart from that,
      it's mostly a matter of taste, whether we attach meta data to
      NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed
      by NMMetaSettingType.
      Note, that previously, _nm_register_setting() was private API. That
      means, no user could subclass a functioning NMSetting instance. The same
      is still true: NMMetaSettingInfo is internal API and users cannot access
      it to create their own NMSetting subclasses. But that is almost desired.
      libnm is not designed, to be extensible via subclassing, nor is it
      clear why that would be a useful thing to do. One day, we should remove
      the NMSetting and NMSettingClass definitions from public headers. Their
      only use is subclassing the types, which however does not work.
      While libnm-core was linking already against nm-meta-setting.c,
      nm_meta_setting_infos was unreferenced. So, this change increases
      the binary size of libnm and NetworkManager (1032 bytes). Note however
      that roughly the same information was previously allocated at runtime.
    • Thomas Haller's avatar
      libnm/trivial: cleanup variable names in settings' class-init functions · 23adc373
      Thomas Haller authored
      - Don't use @parent_class name. This local variable (and @object_class) is
        the class instance up-cast to the pointer types of the parents. The point
        here is not that it is the direct parent. The point is, that it's the
        NMSettingClass type.
        Also, it can only be used inconsistently, in face of NMSettingIP4Config,
        who's parent type is NMSettingIPConfig. Clearly, inside
        nm-setting-ip4-config.c we wouldn't want to use the "parent_class"
        name. Consistently rename @parent_class to @setting_class.
      - Also rename the pointer to the own class to @klass. "setting_class" is also the
        wrong name for that, because the right name would be something like
        However, "klass" is preferred over the latter, because we commonly create new
        GObject implementations by copying an existing one. Generic names like "klass"
        and "self" inside a type implementation make that simpler.
      - drop useless comments like
           /* virtual functions */
           /* Properties */
        It's better to logically and visually structure the code, and avoid trival
        remarks about that. They only end up being used inconsistently. If you
        even need a stronger visual separator, then an 80 char /****/ line
        should be preferred.
  10. 11 Jul, 2018 1 commit
  11. 01 Jul, 2018 1 commit
    • Thomas Haller's avatar
      libnm: avoid constructor function for registering NMSetting types · fa9fe466
      Thomas Haller authored
      constructor functions are ugly, because code is running before
      main() starts. Instead, as the registration code for NMSetting types
      is insid the GType constructor, we just need to ensure at the
      right place, that the GType was created.
      The right place here is _register_settings_ensure_inited(), because
      that is called before we need the registration information.
  12. 28 May, 2018 1 commit
    • Thomas Haller's avatar
      device: hash a per-host key for ipv4.dhcp-client-id=stable · d1a94a85
      Thomas Haller authored
      Otherwise, the generated client-id depends purely on the profile's
      stable-id. It means, the same profile (that is, either the same UUID
      or same stable-id) on different hosts will result in identical client-ids.
      That is clearly not desired. Hash a per-host secret-key as well.
      Note, that we don't hash the interface name. So, activating the
      profile on different interfaces, will still yield the same client-id.
      But also note, that commonly a profile is restricted to one device,
      via "connection.interface-name".
      Note that this is a change in behavior. However, "ipv4.dhcp-client-id=stable"
      was only added recently and not yet released.
      Fixes: 62a78639
  13. 30 Apr, 2018 1 commit
  14. 18 Apr, 2018 2 commits
  15. 06 Apr, 2018 1 commit
  16. 06 Mar, 2018 1 commit
  17. 15 Feb, 2018 2 commits
  18. 04 Jan, 2018 1 commit
    • 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).
  19. 18 Dec, 2017 1 commit
  20. 30 Nov, 2017 1 commit
    • Beniamino Galvani's avatar
      ifcfg-rh: use different variables for IPv4 and IPv6 DNS options · 83797855
      Beniamino Galvani authored
      Until now the ifcfg-rh plugin merged the values of 'ipv4.dns-options'
      and 'ipv6.dns-options' and wrote the result to the RES_OPTIONS
      variable. This is wrong because writing a connection and reading it
      back gives a different connection compared to the original.
      This behavior existed since when DNS options were introduced, but it
      became more evident now that we reread the connection after write,
      because after doing a:
       $ nmcli connection modify ethie ipv4.dns-options ndots:2
      the connection has both ipv4.dns-options and ipv6.dns-options set. In
      order to delete the option, an user has to delete it from both
       $ nmcli connection modify ethie ipv4.dns-options "" ipv6.dns-options ""
      To improve this let's use different variables for IPv4 and IPv6. To
      keep backwards compatibility IPv4 still uses RES_OPTIONS, while IPv6
      uses a new IPV6_RES_OPTIONS variable.
  21. 09 Oct, 2017 1 commit
    • Thomas Haller's avatar
      all: rework configuring route table support by adding "route-table" setting · cc1ee1d2
      Thomas Haller authored
      We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change
      behavior for users that configured policy routing outside of NetworkManager,
      for example, via a dispatcher script. Users had to explicitly opt-in
      for NetworkManager to fully manage all routing tables.
      These settings were awkward. Replace them with new settings "ipv4.route-table"
      and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable
      development branch by removing recently added API.
      As before, a connection will have no route-table set by default. This
      has the meaning that policy-routing is not enabled and only the main table
      will be fully synced. Once the user sets a table, we recognize that and
      NetworkManager manages all routing tables.
      The new route-table setting has other important uses: analog to
      "ipv4.route-metric", it is the default that applies to all routes.
      Currently it only works for static routes, not DHCP, SLAAC,
      default-route, etc. That will be implemented later.
      For static routes, each route still can explicitly set a table, and
      overwrite the per-connection setting in "ipv4.route-table" and
  22. 26 Sep, 2017 1 commit
  23. 25 Jul, 2017 1 commit
  24. 07 Jun, 2017 1 commit
  25. 31 May, 2017 1 commit
    • Lubomir Rintel's avatar
      core: allow two priorities of base settings · 7b5712ac
      Lubomir Rintel authored
      We'll need two "base" settings for Bluetooth NAP connections: bridge to set up
      the actual link and bluetooth to identify the HCI to register the network
      server with.
      Let's use two priorities for base setting, with "1" marking one of higher
      priority and "2" of lower priority when both are present.
  26. 06 Mar, 2017 1 commit
    • Beniamino Galvani's avatar
      ifcfg-rh: support route options · 40e1fd95
      Beniamino Galvani authored
      For IPv4 we support both the legacy and the new route file format. In
      the legacy format, option are appended to the "ip route" command
      metric 3 via dev eth2 cwnd 14 mtu lock 1500
      This is backwards compatible with initscripts. In the new format, a
      OPTIONSx= variable is added to represent the options in the same
      format understood by iproute2:
       OPTIONS0="cwnd 14 mtu lock 1500"
      initscripts do not support this variable at the moment (but the
      changes needed to support it are trivial).
      By default the new format is used, unless the route file is already in
      the legacy format.
      For IPv6 only the legacy format is supported, as before.
  27. 14 Sep, 2016 1 commit
  28. 06 Jul, 2016 1 commit
  29. 12 May, 2016 1 commit
  30. 26 Mar, 2016 1 commit
    • Thomas Haller's avatar
      libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus() · 737c8cc5
      Thomas Haller authored
      In some situations, we want strict checking of errors, for example when
      NetworkManager receives a new connection from a client, the connection
      must make sense as a whole (and since NetworkManager service is backward
      compatible to the clients and not the other way around, there is no
      excuse for sending invalid data to the server).
      In other situations, we want a best-effort behavior. Like when
      NetworkManager sends a connection to its clients, those clients
      want to extract as many properties as they understand, but in order
      to be forward compatible against newer server versions, invalid
      or unknown properties must be accepted.
      Previously, a mixture of both was done. Some issues caused a failure
      to create a new NMSetting, other invalid parts were just silently
      ignored or triggered a g_warning() in glib.
      Now allow for both. When doing strict-validation, be more strict and
      reject all unknown properties and catch when the user sets an invalid
      argument. On the other hand, allow for a best-effort mode that
      effectively cannot fail and will return a new NMSetting instance.
      For now, add NMSettingParseFlags so that the caller can choose the
      old behavior, strict parsing, or best effort.
      This patch doesn't have any externally visible change except that
      no more g_warnings will be emitted.
  31. 19 Feb, 2016 1 commit
    • Thomas Haller's avatar
      all: cleanup includes and let "nm-default.h" include "config.h" · 8bace23b
      Thomas Haller authored
      - All internal source files (except "examples", which are not internal)
        should include "config.h" first. As also all internal source
        files should include "nm-default.h", let "config.h" be included
        by "nm-default.h" and include "nm-default.h" as first in every
        source file.
        We already wanted to include "nm-default.h" before other headers
        because it might contains some fixes (like "nm-glib.h" compatibility)
        that is required first.
      - After including "nm-default.h", we optinally allow for including the
        corresponding header file for the source file at hand. The idea
        is to ensure that each header file is self contained.
      - Don't include "config.h" or "nm-default.h" in any header file
        (except "nm-sd-adapt.h"). Public headers anyway must not include
        these headers, and internal headers are never included after
        "nm-default.h", as of the first previous point.
      - Include all internal headers with quotes instead of angle brackets.
        In practice it doesn't matter, because in our public headers we must
        include other headers with angle brackets. As we use our public
        headers also to compile our interal source files, effectively the
        result must be the same. Still do it for consistency.
      - Except for <config.h> itself. Include it with angle brackets as suggested by
  32. 16 Feb, 2016 1 commit