1. 18 Apr, 2018 1 commit
  2. 06 Apr, 2018 1 commit
  3. 06 Mar, 2018 1 commit
  4. 15 Feb, 2018 2 commits
  5. 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).
  6. 18 Dec, 2017 1 commit
  7. 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.
  8. 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
  9. 26 Sep, 2017 1 commit
  10. 25 Jul, 2017 1 commit
  11. 07 Jun, 2017 1 commit
  12. 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.
  13. 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.
  14. 14 Sep, 2016 1 commit
  15. 06 Jul, 2016 1 commit
  16. 12 May, 2016 1 commit
  17. 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.
  18. 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
  19. 16 Feb, 2016 2 commits
  20. 20 Jan, 2016 1 commit
  21. 23 Nov, 2015 2 commits
  22. 13 Oct, 2015 1 commit
  23. 06 Oct, 2015 1 commit
  24. 05 Aug, 2015 1 commit
  25. 10 Jan, 2015 1 commit
  26. 19 Nov, 2014 3 commits
    • Jiří Klimeš's avatar
    • Dan Winship's avatar
      libnm: Override parts of nm-setting-docs.xml · 36156b70
      Dan Winship authored
      Add "---dbus---" sections to the NMSetting property docs, in the same
      style as the plugin docs, parse them out into a file
      "nm-setting-docs-overrides.xml", and use them to override the GObject
      property docs in nm-setting-docs.xml.
      This lets us put more D-Bus-specific information in the setting docs,
      without cluttering up the property docs, and it also lets us document
      dbus-only properties.
    • Dan Winship's avatar
      libnm, libnm-util: move settings doc generation to libnm-core · c1448698
      Dan Winship authored
      Move the settings/plugins doc generation from libnm-util to
      libnm-core, since libnm-util isn't being updated for all new
      With this commit, the keyfile and ifcfg-rh documentation is basically
      unchanged, except that deprecated properties are now gone, and new
      properties have been added, and the sections are in a different order.
      (generate-plugin-docs.pl just outputs the settings in Makefile order,
      and they were unsorted in libnm-util, but are sorted in libnm-core).
      The settings documentation used for nm-settings.5, the D-Bus API docs,
      and the nmcli help is changed a bit more at this point, and mostly for
      the worse, since the libnm-core setting properties don't match up with
      the D-Bus API as well as the libnm-util ones do. To be fixed...
      (I also removed the "plugins docs" line in each plugin docs comment
      block while moving them, since those blocks will be used for more than
      just plugins soon, and it's sort of obvious anyway.)
  27. 15 Nov, 2014 1 commit
    • Dan Winship's avatar
      libnm-core: change how new and legacy properties are serialized · c785a7df
      Dan Winship authored
      Although libnm filters out properties received from the daemon that it
      doesn't understand, there may be other clients that do not. In
      particular, a client might call GetSettings() on a connection, update
      the ipv4.addresses property in the returned dictionary, and then pass
      the dictionary to Update(). In that case, the updated dictionary would
      contain ipv4.address-data, but it would not reflect the changes the
      client intended to make.
      Fix this by changing the daemon side to prefer the legacy properties
      to the new ones if both are set, and changing the client side to not
      send the legacy properties (since we don't support new clients talking
      to old servers anyway).
  28. 13 Nov, 2014 2 commits
    • Dan Winship's avatar
      libnm*: fix library gettext usage · 53f5e9af
      Dan Winship authored
      Libraries need to include <gi18n-lib.h>, not <gi18n.h>, so that _()
      will get defined to "dgettext (GETTEXT_DOMAIN, string)" rather than
      "gettext (string)" (which will use the program's default domain, which
      works fine for programs in the NetworkManager tree, but not for
      external users). Likewise, we need to call bindtextdomain() so that
      gettext can find the translations if the library is installed in a
      different prefix from the program using it (and
      bind_textdomain_codeset(), so it will know the translations are in
      UTF-8 even if the locale isn't).
      (The fact that no one noticed this was broken before is because the
      libraries didn't really start returning useful translated strings much
      until 0.9.10, and none of the out-of-tree clients have been updated to
      actually show those strings to users yet.)
    • Dan Winship's avatar
      all: consistently include config.h · 3bfb163a
      Dan Winship authored
      config.h should be included from every .c file, and it should be
      included before any other include. Fix that.
      (As a side effect of how I did this, this also changes us to
      consistently use "config.h" rather than <config.h>. To the extent that
      it matters [which is not much], quotes are more correct anyway, since
      we're talking about a file in our own build tree, not a system
  29. 07 Nov, 2014 6 commits
    • Dan Winship's avatar
      libnm-core: don't serialize empty address-labels · ff608c24
      Dan Winship authored
      If no address in an NMSettingIP4Config has a label, then don't bother
      serializing an array of empty strings.
    • Dan Winship's avatar
      libnm-core, libnm, core: add AddressData and RouteData properties · d16905df
      Dan Winship authored
      Add AddressData and RouteData properties to NMSettingIPConfig and
      NMIP[46]Config. These are like the existing "addresses" and "routes"
      properties, but using strings and containing additional attributes,
      like NMIPAddress and NMIPRoute.
      This only affects the D-Bus representations; there are no API changes
      to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the
      additional information is just added to the existing 'addresses' and
      'routes' properties.
      NMSettingIP4Config and NMSettingIP6Config now always generate both
      old-style data ('addresses', 'address-labels', 'routes') and new-style
      data ('address-data', 'gateway', 'route-data') when serializing to
      D-Bus, for backward compatibility. When deserializing, they will fill
      in the 'addresses' and 'routes' properties from the new-style data if
      it is present (ignoring the old-style data), or from the old-style
      data if the new-style isn't present.
      The daemon-side NMIP4Config and NMIP6Config always emit changes for
      both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The
      libnm-side classes initially listen for changes on both properties,
      but start ignoring the 'Addresses' and 'Routes' properties once they
      know the daemon is also providing 'AddressData' and 'RouteData'.
    • Dan Winship's avatar
      libnm-core: add NMSettingIPConfig:gateway, drop NMIPAddress:gateway · f17699f4
      Dan Winship authored
      The gateway is a global property of the IPv4/IPv6 configuration, not
      an attribute of any particular address. So represent it as such in the
      API; remove the gateway from NMIPAddress, and add it to
      Behind the scenes, the gateway is still serialized along with the
      first address in NMSettingIPConfig:addresses, and is deserialized from
      that if the settings dictionary doesn't contain a 'gateway' key.
      Adjust nmcli's interactive mode to prompt for IP addresses and gateway
      separately. (Patch partly from Jirka Klimeš.)
    • Dan Winship's avatar
      libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes · 3f30c6f1
      Dan Winship authored
      Split a base NMSettingIPConfig class out of NMSettingIP4Config and
      NMSettingIP6Config, and update things accordingly.
      Further simplifications of now-redundant IPv4-vs-IPv6 code are
      possible, and should happen in the future.
    • Dan Winship's avatar
      libnm-core: add NMIPAddress/NMIPRoute attributes, use for labels · 39709fdc
      Dan Winship authored
      Add key-value attributes to NMIPAddress and NMIPRoute, and use them to
      store IPv4 address labels. Demote NMSettingIP4Config:address-labels to
      a D-Bus-only property, and arrange for :addresses setter to read the
      labels out of that property when creating the addresses.
    • Dan Winship's avatar
      libnm-core, all: merge IPv4 and IPv6 address/route types · 21c8a6b2
      Dan Winship authored
      Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route
      and NMIP6Route into NMIPRoute. The new types represent IP addresses as
      strings, rather than in binary, and so are address-family agnostic.