1. 05 May, 2017 2 commits
  2. 03 Oct, 2016 1 commit
  3. 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
        https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
      8bace23b
  4. 22 Jan, 2016 1 commit
    • Thomas Haller's avatar
      libnm-core: fail verify() for NMSettingVlan for invalid vlan id · 8715d614
      Thomas Haller authored
      Point in case:
      
          # ip link add link dummy0 name dummy0.vlan type vlan id 4095
          RTNETLINK answers: Numerical result out of range
      
      This potentially causes existing (invalid) connections to disappear
      as they now fail verification.
      
      Instead of adjusting the range of the GObject property
      NM_SETTING_VLAN_ID, reject it during vlan. This is a bit more
      forgiving to an older client that isn't aware of this new restriction,
      so he can first set the value without raising a critical warning.
      8715d614
  5. 27 Oct, 2015 1 commit
  6. 23 Oct, 2015 1 commit
    • Thomas Haller's avatar
      libnm: treat missing NMSettingVlan:flags property as old default value · 21674d5b
      Thomas Haller authored
      We changed the default value of MSettingVlan:flags from 0 to
      1 (NM_VLAN_FLAG_REORDER_HEADERS). That means, that old libnm
      clients will not serialize 0 (their default).
      This change broke the D-Bus API. The D-Bus API allows to omit a value
      when meaning the default value. That means, we cannot change the
      default value (in the D-Bus API!) without breaking previous assumptions.
      
      A newer libnm version should treat a missing flags argument as the
      old default value and thus preserve the original default value (in the
      D-Bus API).
      
      This has the downside that for the future we will continue to treat a missing
      value as the old default value (0), and in order to get the new default
      value (1), the client must explicitly set the flags.
      
      We also must restore the original default value in libnm-glib.
      libnm-glib does not support _nm_setting_class_override_property()
      and thus it must keep thinking that the default value for the GObject
      property continues to be 0. Otherwise, it would not serialize a 1, which
      a new libnm would now interpret as 0.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1250225
      
      Fixes: 687b6515
      21674d5b
  7. 07 Oct, 2015 1 commit
    • Jiří Klimeš's avatar
      libnm/vlan: default to vlan.flags=REORDER_HDR for new connections (rh #1250225) · 687b6515
      Jiří Klimeš authored
      The kernel defaults REORDER_HDR to 1 when creating a new VLAN, but
      NetworkManager's VLAN flags property defaulted to 0. Thus REORDER_HDR was not
      set for NM-created VLANs with default values.
      
      We want to match the kernel default, so we change the default value for the
      vlan.flags property. However, we do not want to change the flags for existing
      connections if the property is missing in connection files. Thus we have to
      update plugins for that. We also make sure that vlan.flags is always written
      by 'keyfile' when the value is default. That way new connections have flags
      property explicitly written and it will be loaded as expected.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1250225
      687b6515
  8. 05 Aug, 2015 1 commit
  9. 15 Dec, 2014 1 commit
    • Jiří Klimeš's avatar
      libnm-core: mute coverity for RESOURCE_LEAK (CWE-772) in g_return_val_if_fail() · afb0e2c5
      Jiří Klimeš authored
      Error: RESOURCE_LEAK (CWE-772): [#def10]
      NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:225: alloc_fn: Storage is returned from allocation function "priority_map_new_from_str".
      NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:154:4: alloc_fn: Storage is returned from allocation function "g_malloc0".
      NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:154:4: var_assign: Assigning: "p" = "g_malloc0(8UL)".
      NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:164:2: return_alloc: Returning allocated memory "p".
      NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:225: var_assign: Assigning: "item" = storage returned from "priority_map_new_from_str(map, str)".
      NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:226: leaked_storage: Variable "item" going out of scope leaks the storage it points to.
      
      Error: RESOURCE_LEAK (CWE-772): [#def11]
      NetworkManager-0.9.11.0/libnm-core/nm-utils.c:2056: alloc_fn: Storage is returned from allocation function "crypto_make_des_aes_key".
      NetworkManager-0.9.11.0/libnm-core/crypto.c:405:2: alloc_fn: Storage is returned from allocation function "g_malloc0".
      NetworkManager-0.9.11.0/libnm-core/crypto.c:405:2: var_assign: Assigning: "key" = "g_malloc0(digest_len + 1U)".
      NetworkManager-0.9.11.0/libnm-core/crypto.c:407:2: noescape: Resource "key" is not freed or pointed-to in function "crypto_md5_hash".
      NetworkManager-0.9.11.0/libnm-core/crypto.c:769:24: noescape: "crypto_md5_hash(char const *, gssize, char const *, gssize, char *, gsize)" does not free or save its pointer parameter "buffer".
      NetworkManager-0.9.11.0/libnm-core/crypto.c:415:2: return_alloc: Returning allocated memory "key".
      NetworkManager-0.9.11.0/libnm-core/nm-utils.c:2056: var_assign: Assigning: "key" = storage returned from "crypto_make_des_aes_key("DES-EDE3-CBC", &salt[0], salt_len, in_password, &key_len, NULL)".
      NetworkManager-0.9.11.0/libnm-core/nm-utils.c:2057: leaked_storage: Variable "key" going out of scope leaks the storage it points to.
      afb0e2c5
  10. 19 Nov, 2014 1 commit
    • 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
      properties.
      
      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.)
      c1448698
  11. 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.)
      53f5e9af
    • 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
      include.)
      3bfb163a
  12. 29 Aug, 2014 1 commit
  13. 15 Jul, 2014 2 commits
    • Dan Winship's avatar
      libnm-util, libnm-glib: whitespace fixes · 2570c5a1
      Dan Winship authored
      Fix indentation, kill trailing whitespace, split some long lines.
      2570c5a1
    • Dan Winship's avatar
      libnm-util, libnm-glib: standardize copyright/license headers · cb7e1893
      Dan Winship authored
      - Remove list of authors from files that had them; these serve no
        purpose except to quickly get out of date (and were only used in
        libnm-util and not libnm-glib anyway).
      
      - Just say "Copyright", not "(C) Copyright" or "Copyright (C)"
      
      - Put copyright statement after the license, not before
      
      - Remove "NetworkManager - Network link manager" from the few files
        that contained it, and "libnm_glib -- Access network status &
        information from glib applications" from the many files that
        contained it.
      
      - Remove vim modeline from nm-device-olpc-mesh.[ch], add emacs modeline
        to files that were missing it.
      cb7e1893
  14. 30 Jun, 2014 1 commit
    • Thomas Haller's avatar
      libnm-util: normalize virtual_iface_name in NMSettings · 2deaa539
      Thomas Haller authored
      Some type-specific NMSetting implementations (bond, bridge, team, vlan)
      have their own 'interface-name' property. This property will be
      deprecated in favour of 'interface-name' in NMSettingConnection.
      
      Change verify() and normalize() to check that the redundant
      values match and repair/normalize the properties.
      
      Force the virtual interface name of the type-specific setting to be
      equal to NMSettingConnection:interface_name. This way, the depreacted
      field stays valid and backward compatible.
      
      NMSettingInfiniband is special, because it does not have a backing
      property for the interface name, although it implements
      get_virtual_iface_name(). To account for this, some special handling
      is needed in order not to change the behaviour of get_virtual_iface_name().
      Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
      2deaa539
  15. 19 Jun, 2014 3 commits
    • Dan Winship's avatar
      libnm-util: remove NMSetting* GParamSpec docs · cdc15cb2
      Dan Winship authored
      Remove all the GParamSpec docs, since everything now uses the gtk-doc
      docs instead, so there's no point in having two copies of each (which
      are often out of sync anyway).
      
      Since we're touching so many lines anyway, also fix up the indentation
      of the remaining property-installing lines, and add
      G_PARAM_STATIC_STRINGS to each paramspec (so the nick strings don't
      get strduped). Also, be consistent about starting a new line between
      "g_object_class_install_property" and its opening parenthesis.
      cdc15cb2
    • Dan Winship's avatar
      libnm-util: various NMSetting* property doc fixes/improvements · e8577083
      Dan Winship authored
      Fix up various issues with the docs for the NMSetting properties, and
      pull in text from the GParamSpec docs where the GParamSpec docs were
      better (or contained information that is necessary in the context of
      nm-settings.5).
      
      Also, consistently wrap all of the doc comments to the same width (80
      columns).
      e8577083
    • Dan Winship's avatar
      libnm-util: fix gtk-doc bugs in NMSetting* properties · 9de24b16
      Dan Winship authored
      Fix misused gtk-doc annotations and incorrectly-identified properties.
      
      In particular, the upcoming introspection-based generate-settings-spec
      expands macro and enum values, so if you use '%' where you should have
      used '#', it will fail to find an expansion, and error out.
      9de24b16
  16. 05 Mar, 2014 1 commit
  17. 28 Feb, 2014 1 commit
  18. 24 Feb, 2014 1 commit
  19. 12 Dec, 2013 1 commit
    • Thomas Haller's avatar
      libnm-util: refactor NMSetting name and register_settings · 9d319e6d
      Thomas Haller authored
      - refactor register_settings to allow lookup by GType and
        add the settings name to SettingInfo.
      
      - setting NM_SETTING_NAME is deprecated and should not be set anymore.
        Indeed it has always be a bug, to reset the name to a different value.
        The only valid place to set the name was in the _init() function of
        the derived class itself.
        This is now no longer needed/possible. Instead the name get's
        detected based on the registered setting types. This makes use of
        the registered metadata that is available anyway since every
        usable setting has to register itself.
      Signed-off-by: Thomas Haller's avatarThomas Haller <thaller@redhat.com>
      9d319e6d
  20. 05 Dec, 2013 1 commit
  21. 02 Dec, 2013 1 commit
  22. 27 Nov, 2013 1 commit
  23. 13 Nov, 2013 1 commit
  24. 03 Oct, 2013 1 commit
  25. 12 Sep, 2013 1 commit
    • Dan Winship's avatar
      all: standardize on NMSettingWired:mac-address for all VLANs · 066b5922
      Dan Winship authored
      Currently, ethernet-based VLANs can specify the hardware address of
      the parent device (and, in theory, the cloned hardware address and MTU
      of the VLAN device) by using an NMSettingWired in addition to the
      NMSettingVlan.
      
      The theory was that non-ethernet-based VLANs, when we eventually
      supported them, would likewise use the setting type corresponding to
      their parent device. However, this turns out to be both complicated
      (the settings plugins and connection editor would have a
      hard-to-impossible time figuring out which setting type to use in some
      cases) and incorrect (for most L2 settings [eg, BSSID, bond mode,
      etc], the VLAN can't have its own values separate from the parent
      device).
      
      What we should have done was just have :mac-address,
      :cloned-mac-address, and :mtu properties on NMSettingVlan. However, at
      this point, for backward-compatibility, we will just stick with using
      a combination of NMSettingVlan and NMSettingWired, but we will use
      NMSettingWired regardless of the underlying hardware type.
      066b5922
  26. 13 Jun, 2013 1 commit
  27. 29 May, 2013 1 commit
  28. 28 May, 2013 1 commit
  29. 12 Apr, 2013 1 commit
  30. 03 Apr, 2013 1 commit
  31. 13 Mar, 2013 1 commit
  32. 25 Feb, 2013 1 commit
  33. 18 Feb, 2013 1 commit
  34. 15 Feb, 2013 1 commit
    • Dan Winship's avatar
      libnm-utils: add :carrier-detect properties · 5266e25e
      Dan Winship authored
      For settings corresponding to devices that have a :carrier property
      (ie bond, bridge, infiniband, vlan, and wired), add a :carrier-detect
      property specifying how that affects the connection:
      
        yes: The connection can only be activated when the device
            has carrier, and will be deactivated if the device loses
            carrier (for more than 4 seconds).
        no: The connection ignores carrier on the device; it can be
            activated when there is no carrier, and stays activated
            when carrier is lost.
        on-activate: The connection can only be activated when the
            device has carrier, but it will not be deactivated if the
            device loses carrier.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=688284
      5266e25e
  35. 29 Nov, 2012 1 commit