2009-07-30 01:34:52 +00:00
|
|
|
<?xml version="1.0" encoding="UTF-8" ?>
|
|
|
|
|
|
|
|
<node name="/" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
|
|
|
|
<interface name="org.freedesktop.NetworkManager.IP6Config">
|
libnm-core, libnm, core: add AddressData and RouteData properties
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'.
2014-10-21 12:33:18 +00:00
|
|
|
<property name="Addresses" type="a(ayuay)" access="read">
|
|
|
|
<tp:docstring>
|
|
|
|
Array of tuples of IPv6 address/prefix/gateway.
|
|
|
|
|
|
|
|
Deprecated: use AddressData and Gateway.
|
|
|
|
</tp:docstring>
|
|
|
|
</property>
|
|
|
|
<property name="AddressData" type="aa{sv}" access="read">
|
|
|
|
<tp:docstring>
|
|
|
|
Array of IP address data objects. All addresses will include
|
|
|
|
"address" (an IP address string), and "prefix" (a uint). Some
|
|
|
|
addresses may include additional attributes.
|
|
|
|
</tp:docstring>
|
|
|
|
</property>
|
2013-09-06 09:56:41 +00:00
|
|
|
<property name="Gateway" type="s" access="read">
|
|
|
|
<tp:docstring>The gateway in use.</tp:docstring>
|
|
|
|
</property>
|
|
|
|
<property name="Routes" type="a(ayuayu)" access="read">
|
libnm-core, libnm, core: add AddressData and RouteData properties
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'.
2014-10-21 12:33:18 +00:00
|
|
|
<tp:docstring>
|
|
|
|
Tuples of IPv6 route/prefix/next-hop/metric.
|
|
|
|
|
|
|
|
Deprecated: use RouteData
|
|
|
|
</tp:docstring>
|
|
|
|
</property>
|
|
|
|
<property name="RouteData" type="aa{sv}" access="read">
|
|
|
|
<tp:docstring>
|
|
|
|
Array of IP route data objects. All routes will include "dest"
|
|
|
|
(an IP address string) and "prefix" (a uint). Some routes may
|
|
|
|
include "next-hop" (an IP address string), "metric" (a uint),
|
|
|
|
and additional attributes.
|
|
|
|
</tp:docstring>
|
2013-09-06 09:56:41 +00:00
|
|
|
</property>
|
2009-07-30 01:34:52 +00:00
|
|
|
<property name="Nameservers" type="aay" access="read">
|
2015-04-15 18:53:30 +00:00
|
|
|
<!-- gdbus-codegen assumes that "aay" means "array of non-UTF-8
|
|
|
|
string" and so would make this a char **.
|
|
|
|
-->
|
|
|
|
<annotation name="org.gtk.GDBus.C.ForceGVariant" value="1"/>
|
2009-07-30 01:34:52 +00:00
|
|
|
<tp:docstring>The nameservers in use.</tp:docstring>
|
|
|
|
</property>
|
|
|
|
<property name="Domains" type="as" access="read">
|
|
|
|
<tp:docstring>A list of domains this address belongs to.</tp:docstring>
|
|
|
|
</property>
|
2013-09-06 09:56:41 +00:00
|
|
|
<property name="Searches" type="as" access="read">
|
|
|
|
<tp:docstring>A list of dns searches.</tp:docstring>
|
2009-07-30 01:34:52 +00:00
|
|
|
</property>
|
2015-03-26 08:23:12 +00:00
|
|
|
<property name="DnsOptions" type="as" access="read">
|
|
|
|
<tp:docstring>
|
|
|
|
A list of DNS options that modify the behavior of the DNS
|
|
|
|
resolver. See resolv.conf(5) manual page for the list of
|
|
|
|
supported options.
|
|
|
|
</tp:docstring>
|
|
|
|
</property>
|
2014-01-08 23:53:04 +00:00
|
|
|
|
|
|
|
<signal name="PropertiesChanged">
|
|
|
|
<arg name="properties" type="a{sv}" tp:type="String_Variant_Map">
|
|
|
|
<tp:docstring>
|
|
|
|
A dictionary mapping property names to variant boxed values
|
|
|
|
</tp:docstring>
|
|
|
|
</arg>
|
|
|
|
</signal>
|
2009-07-30 01:34:52 +00:00
|
|
|
</interface>
|
|
|
|
</node>
|
|
|
|
|