1. 07 Nov, 2014 1 commit
    • 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'.
      d16905df
  2. 23 Jan, 2014 1 commit
  3. 25 Sep, 2013 1 commit
  4. 18 Apr, 2010 1 commit
    • Dan Williams's avatar
      core: fix Address property type of IP6Config objects · 1d409aeb
      Dan Williams authored
      We can change the property's D-Bus signature (and thus API) here
      because querying the IP6Config object's properties caused NM to
      crash.  Apparently we forgot to change the type of the Address
      property when we C&P-ed the IP4Config into the IP6Config, and
      DBUS_TYPE_G_ARRAY_OF_ARRAY_OF_UINT is certainly the wrong type
      to use since the backing object that dbus-glib would marshal
      into the ARRAY_OF_ARRAY_OF_UINT wasn't that type, causing a
      crash in dbus-glib when a client got the IP6Config.
      1d409aeb
  5. 30 Jul, 2009 1 commit