2007-02-16 11:23:49 +00:00
|
|
|
<?xml version="1.0" encoding="UTF-8" ?>
|
|
|
|
|
|
2008-02-28 02:07:21 +00:00
|
|
|
<node name="/" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
|
2007-02-16 11:23:49 +00:00
|
|
|
<interface name="org.freedesktop.NetworkManager.IP4Config">
|
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 08:33:18 -04:00
|
|
|
<property name="Addresses" type="aau" access="read">
|
|
|
|
|
<tp:docstring>
|
|
|
|
|
Array of arrays of IPv4 address/prefix/gateway. All 3
|
|
|
|
|
elements of each array are in network byte order. Essentially:
|
|
|
|
|
[(addr, prefix, gateway), (addr, 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 11:56:41 +02:00
|
|
|
<property name="Gateway" type="s" access="read">
|
|
|
|
|
<tp:docstring>The gateway in use.</tp:docstring>
|
|
|
|
|
</property>
|
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 08:33:18 -04:00
|
|
|
<property name="Routes" type="aau" access="read">
|
|
|
|
|
<tp:docstring>
|
|
|
|
|
Arrays of IPv4 route/prefix/next-hop/metric. All 4 elements of
|
|
|
|
|
each tuple are in network byte order. 'route' and 'next hop'
|
|
|
|
|
are IPv4 addresses, while prefix and metric are simple
|
|
|
|
|
unsigned integers. Essentially: [(route, prefix, next-hop,
|
|
|
|
|
metric), (route, prefix, next-hop, metric), ...]
|
|
|
|
|
|
|
|
|
|
Deprecated: use RouteData
|
2009-10-23 15:38:06 -07:00
|
|
|
</tp:docstring>
|
2008-02-28 02:07:21 +00:00
|
|
|
</property>
|
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 08:33:18 -04:00
|
|
|
<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.
|
2009-10-23 15:38:06 -07:00
|
|
|
</tp:docstring>
|
2008-08-06 22:23:48 +00:00
|
|
|
</property>
|
2013-09-06 11:56:41 +02:00
|
|
|
<property name="Nameservers" type="au" access="read">
|
|
|
|
|
<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>
|
|
|
|
|
<property name="Searches" type="as" access="read">
|
|
|
|
|
<tp:docstring>A list of dns searches.</tp:docstring>
|
|
|
|
|
</property>
|
2015-03-26 09:23:12 +01: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>
|
2013-09-06 11:56:41 +02:00
|
|
|
<property name="WinsServers" type="au" access="read">
|
|
|
|
|
<tp:docstring>The Windows Internet Name Service servers associated with the connection. Each address is in network byte order.</tp:docstring>
|
|
|
|
|
</property>
|
2014-01-08 17:53:04 -06: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>
|
2007-02-16 11:23:49 +00:00
|
|
|
</interface>
|
|
|
|
|
</node>
|
|
|
|
|
|
