2007-09-12 16:23:53 +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-09-12 16:23:53 +00:00
|
|
|
<interface name="org.freedesktop.NetworkManager.VPN.Plugin">
|
2014-09-10 13:51:53 -04:00
|
|
|
<annotation name="org.gtk.GDBus.C.Name" value="VpnPlugin"/>
|
|
|
|
|
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
This interface is provided by plugins providing VPN services to the NetworkManager daemon.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2013-06-18 09:32:53 -05:00
|
|
|
|
2007-09-12 16:23:53 +00:00
|
|
|
<method name="Connect">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2013-06-18 09:32:53 -05:00
|
|
|
Tells the plugin to connect. Interactive secrets requests (eg, emitting
|
|
|
|
|
the SecretsRequired signal) are not allowed.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2007-09-12 16:23:53 +00:00
|
|
|
<annotation name="org.freedesktop.DBus.GLib.CSymbol" value="impl_vpn_plugin_connect"/>
|
2008-02-28 02:07:21 +00:00
|
|
|
<arg name="connection" type="a{sa{sv}}" direction="in" tp:type="String_String_Variant_Map_Map">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
Describes the connection to be established.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-02-28 02:07:21 +00:00
|
|
|
</arg>
|
|
|
|
|
<tp:possible-errors>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.StartingInProgress"/>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.AlreadyStarted"/>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.StoppingInProgress"/>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.BadArguments"/>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.LaunchFailed"/>
|
2013-06-18 09:32:53 -05:00
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.WrongState"/>
|
|
|
|
|
</tp:possible-errors>
|
|
|
|
|
</method>
|
|
|
|
|
|
|
|
|
|
<method name="ConnectInteractive">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2013-06-18 09:32:53 -05:00
|
|
|
Tells the plugin to connect, allowing interactive secrets requests (eg
|
|
|
|
|
the plugin is allowed to emit the SecretsRequired signal if the VPN
|
|
|
|
|
service indicates that it needs additional secrets during the connect
|
|
|
|
|
process).
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2013-06-18 09:32:53 -05:00
|
|
|
<annotation name="org.freedesktop.DBus.GLib.CSymbol" value="impl_vpn_plugin_connect_interactive"/>
|
|
|
|
|
<arg name="connection" type="a{sa{sv}}" direction="in" tp:type="String_String_Variant_Map_Map">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2013-06-18 09:32:53 -05:00
|
|
|
Describes the connection to be established.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2013-06-18 09:32:53 -05:00
|
|
|
</arg>
|
|
|
|
|
<arg name="details" type="a{sv}" direction="in" tp:type="String_Variant_Map">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2013-06-18 09:32:53 -05:00
|
|
|
Additional details about the Connect process.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2013-06-18 09:32:53 -05:00
|
|
|
</arg>
|
|
|
|
|
<tp:possible-errors>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.StartingInProgress"/>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.AlreadyStarted"/>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.StoppingInProgress"/>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.BadArguments"/>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.LaunchFailed"/>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.WrongState"/>
|
2013-09-26 10:19:33 +02:00
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.InteractiveNotSupported"/>
|
2008-02-28 02:07:21 +00:00
|
|
|
</tp:possible-errors>
|
2007-09-12 16:23:53 +00:00
|
|
|
</method>
|
|
|
|
|
|
2007-09-27 02:20:53 +00:00
|
|
|
<method name="NeedSecrets">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
Asks the plugin whether the provided connection will require secrets to connect successfully.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2007-09-27 02:20:53 +00:00
|
|
|
<annotation name="org.freedesktop.DBus.GLib.CSymbol" value="impl_vpn_plugin_need_secrets"/>
|
2008-02-28 02:07:21 +00:00
|
|
|
<arg name="settings" type="a{sa{sv}}" direction="in" tp:type="String_String_Variant_Map_Map">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
Describes the connection that may need secrets.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-02-28 02:07:21 +00:00
|
|
|
</arg>
|
|
|
|
|
<arg name="setting_name" type="s" direction="out">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
The setting name within the provided connection that requires secrets, if any.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-02-28 02:07:21 +00:00
|
|
|
</arg>
|
|
|
|
|
<tp:possible-errors>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.ConnectionInvalid"/>
|
|
|
|
|
</tp:possible-errors>
|
2007-09-27 02:20:53 +00:00
|
|
|
</method>
|
|
|
|
|
|
2007-09-12 16:23:53 +00:00
|
|
|
<method name="Disconnect">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
Disconnect the plugin.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2007-09-12 16:23:53 +00:00
|
|
|
<annotation name="org.freedesktop.DBus.GLib.CSymbol" value="impl_vpn_plugin_disconnect"/>
|
2008-02-28 02:07:21 +00:00
|
|
|
<tp:possible-errors>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.StoppingInProgress"/>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.AlreadyStopped"/>
|
|
|
|
|
</tp:possible-errors>
|
2007-09-12 16:23:53 +00:00
|
|
|
</method>
|
|
|
|
|
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
<method name="SetConfig">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
Set generic connection details on the connection.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
<annotation name="org.freedesktop.DBus.GLib.CSymbol" value="impl_vpn_plugin_set_config"/>
|
|
|
|
|
<arg name="config" type="a{sv}" direction="in" tp:type="String_Variant_Map">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
Generic configuration details for the connection.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
</arg>
|
|
|
|
|
</method>
|
|
|
|
|
|
2007-09-12 16:23:53 +00:00
|
|
|
<method name="SetIp4Config">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
Set IPv4 details on the connection.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2007-09-12 16:23:53 +00:00
|
|
|
<annotation name="org.freedesktop.DBus.GLib.CSymbol" value="impl_vpn_plugin_set_ip4_config"/>
|
2008-02-28 02:07:21 +00:00
|
|
|
<arg name="config" type="a{sv}" direction="in" tp:type="String_Variant_Map">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
Ip4Config details for the connection. You must call
|
|
|
|
|
SetConfig() before calling this.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
</arg>
|
|
|
|
|
</method>
|
|
|
|
|
|
|
|
|
|
<method name="SetIp6Config">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
Set IPv6 details on the connection.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
<annotation name="org.freedesktop.DBus.GLib.CSymbol" value="impl_vpn_plugin_set_ip6_config"/>
|
|
|
|
|
<arg name="config" type="a{sv}" direction="in" tp:type="String_Variant_Map">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
Ip6Config details for the connection. You must call
|
|
|
|
|
SetConfig() before calling this.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-02-28 02:07:21 +00:00
|
|
|
</arg>
|
2007-09-12 16:23:53 +00:00
|
|
|
</method>
|
|
|
|
|
|
|
|
|
|
<method name="SetFailure">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
Indicate a failure to the plugin.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2007-09-12 16:23:53 +00:00
|
|
|
<annotation name="org.freedesktop.DBus.GLib.CSymbol" value="impl_vpn_plugin_set_failure"/>
|
2008-02-28 02:07:21 +00:00
|
|
|
<arg name="reason" type="s" direction="in">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
The reason for the failure.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-02-28 02:07:21 +00:00
|
|
|
</arg>
|
2007-09-12 16:23:53 +00:00
|
|
|
</method>
|
|
|
|
|
|
2014-07-07 09:35:07 -04:00
|
|
|
<property name="State" type="u" access="read" tp:type="NM_VPN_SERVICE_STATE">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
The state of the plugin.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-02-28 02:07:21 +00:00
|
|
|
</property>
|
2007-09-12 16:23:53 +00:00
|
|
|
|
|
|
|
|
<signal name="StateChanged">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
Emitted when the plugin state changes.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2014-07-07 09:35:07 -04:00
|
|
|
<arg name="state" type="u" tp:type="NM_VPN_SERVICE_STATE">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
The new state of the plugin.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-02-28 02:07:21 +00:00
|
|
|
</arg>
|
2007-09-12 16:23:53 +00:00
|
|
|
</signal>
|
|
|
|
|
|
2013-06-18 09:32:53 -05:00
|
|
|
<signal name="SecretsRequired">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2013-06-18 09:32:53 -05:00
|
|
|
Emitted during an ongoing ConnectInteractive() request when the plugin
|
|
|
|
|
has determined that new secrets are required. NetworkManager will then
|
|
|
|
|
call the NewSecrets() method with a connection hash including the new
|
|
|
|
|
secrets.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2013-06-18 09:32:53 -05:00
|
|
|
<arg name="message" type="s" direction="out">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2013-06-18 09:32:53 -05:00
|
|
|
Informational message, if any, about the request. For example, if
|
|
|
|
|
a second PIN is required, could indicate to the user to wait for
|
|
|
|
|
the token code to change until entering the next PIN.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2013-06-18 09:32:53 -05:00
|
|
|
</arg>
|
|
|
|
|
<arg name="secrets" type="as" direction="out">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2013-06-18 09:32:53 -05:00
|
|
|
Array of strings of VPN secret names which the plugin thinks
|
|
|
|
|
secrets may be required for, or other VPN-specific data to be
|
|
|
|
|
processed by the VPN's front-end.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2013-06-18 09:32:53 -05:00
|
|
|
</arg>
|
|
|
|
|
</signal>
|
|
|
|
|
|
|
|
|
|
<method name="NewSecrets">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2013-06-18 09:32:53 -05:00
|
|
|
Called in response to a SecretsRequired signal to deliver updated secrets
|
|
|
|
|
or other information to the plugin.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2013-06-18 09:32:53 -05:00
|
|
|
<annotation name="org.freedesktop.DBus.GLib.CSymbol" value="impl_vpn_plugin_new_secrets"/>
|
|
|
|
|
<arg name="connection" type="a{sa{sv}}" direction="in" tp:type="String_String_Variant_Map_Map">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2013-06-18 09:32:53 -05:00
|
|
|
Describes the connection including the new secrets.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2013-06-18 09:32:53 -05:00
|
|
|
</arg>
|
|
|
|
|
<tp:possible-errors>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.WrongState"/>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.BadArguments"/>
|
|
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.LaunchFailed"/>
|
2013-09-26 10:19:33 +02:00
|
|
|
<tp:error name="org.freedesktop.NetworkManager.VPN.Error.InteractiveNotSupported"/>
|
2013-06-18 09:32:53 -05:00
|
|
|
</tp:possible-errors>
|
|
|
|
|
</method>
|
|
|
|
|
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
<signal name="Config">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
The plugin obtained generic configuration information.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
<arg name="config" type="a{sv}" tp:type="String_Variant_Map">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
The configuration information.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
</arg>
|
|
|
|
|
</signal>
|
|
|
|
|
|
2007-09-12 16:23:53 +00:00
|
|
|
<signal name="Ip4Config">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
The plugin obtained an IPv4 configuration.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-02-28 02:07:21 +00:00
|
|
|
<arg name="ip4config" type="a{sv}" tp:type="String_Variant_Map">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
The IPv4 configuration.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-02-28 02:07:21 +00:00
|
|
|
</arg>
|
2007-09-12 16:23:53 +00:00
|
|
|
</signal>
|
|
|
|
|
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
<signal name="Ip6Config">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
The plugin obtained an IPv6 configuration.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
<arg name="ip6config" type="a{sv}" tp:type="String_Variant_Map">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
The IPv6 configuration.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
vpn: support IPv6 over VPNs
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
2012-05-04 15:50:07 -04:00
|
|
|
</arg>
|
|
|
|
|
</signal>
|
|
|
|
|
|
2007-09-12 16:23:53 +00:00
|
|
|
<signal name="LoginBanner">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
Emitted when the plugin receives a login banner from the VPN service.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-02-28 02:07:21 +00:00
|
|
|
<arg name="banner" type="s">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
The login banner string.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-02-28 02:07:21 +00:00
|
|
|
</arg>
|
2007-09-12 16:23:53 +00:00
|
|
|
</signal>
|
|
|
|
|
|
|
|
|
|
<signal name="Failure">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
Emitted when a failure in the VPN plugin occurs.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-09-22 15:29:00 +00:00
|
|
|
<arg name="reason" type="u" tp:type="NM_VPN_PLUGIN_FAILURE">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-02-28 02:07:21 +00:00
|
|
|
Reason code for the failure.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-02-28 02:07:21 +00:00
|
|
|
</arg>
|
2007-09-12 16:23:53 +00:00
|
|
|
</signal>
|
2008-09-22 15:29:00 +00:00
|
|
|
|
2014-07-07 09:35:07 -04:00
|
|
|
<tp:enum name="NM_VPN_SERVICE_STATE" type="u">
|
|
|
|
|
<tp:enumvalue suffix="UNKNOWN" value="0">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2014-07-07 09:35:07 -04:00
|
|
|
The state of the VPN plugin is unknown.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2014-07-07 09:35:07 -04:00
|
|
|
</tp:enumvalue>
|
|
|
|
|
<tp:enumvalue suffix="INIT" value="1">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2014-07-07 09:35:07 -04:00
|
|
|
The VPN plugin is initialized.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2014-07-07 09:35:07 -04:00
|
|
|
</tp:enumvalue>
|
|
|
|
|
<tp:enumvalue suffix="SHUTDOWN" value="2">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2014-07-07 09:35:07 -04:00
|
|
|
(Not used.)
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2014-07-07 09:35:07 -04:00
|
|
|
</tp:enumvalue>
|
|
|
|
|
<tp:enumvalue suffix="STARTING" value="3">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2014-07-07 09:35:07 -04:00
|
|
|
The plugin is attempting to connect to a VPN server.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2014-07-07 09:35:07 -04:00
|
|
|
</tp:enumvalue>
|
|
|
|
|
<tp:enumvalue suffix="STARTED" value="4">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2014-07-07 09:35:07 -04:00
|
|
|
The plugin has connected to a VPN server.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2014-07-07 09:35:07 -04:00
|
|
|
</tp:enumvalue>
|
|
|
|
|
<tp:enumvalue suffix="STOPPING" value="5">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2014-07-07 09:35:07 -04:00
|
|
|
The plugin is disconnecting from the VPN server.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2014-07-07 09:35:07 -04:00
|
|
|
</tp:enumvalue>
|
|
|
|
|
<tp:enumvalue suffix="STOPPED" value="6">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2014-07-07 09:35:07 -04:00
|
|
|
The plugin has disconnected from the VPN server.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2014-07-07 09:35:07 -04:00
|
|
|
</tp:enumvalue>
|
|
|
|
|
</tp:enum>
|
|
|
|
|
|
2008-09-22 15:29:00 +00:00
|
|
|
<tp:enum name="NM_VPN_PLUGIN_FAILURE" type="u">
|
|
|
|
|
<tp:enumvalue suffix="LOGIN_FAILED" value="0">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-09-22 15:29:00 +00:00
|
|
|
Login failed.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-09-22 15:29:00 +00:00
|
|
|
</tp:enumvalue>
|
|
|
|
|
<tp:enumvalue suffix="CONNECT_FAILED" value="1">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-09-22 15:29:00 +00:00
|
|
|
Connect failed.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-09-22 15:29:00 +00:00
|
|
|
</tp:enumvalue>
|
|
|
|
|
<tp:enumvalue suffix="BAD_IP_CONFIG" value="2">
|
2016-03-24 14:36:14 +01:00
|
|
|
<annotation name="org.gtk.GDBus.DocString" value="
|
2008-09-22 15:29:00 +00:00
|
|
|
Invalid IP configuration returned from the VPN plugin.
|
2016-03-24 14:36:14 +01:00
|
|
|
" />
|
2008-09-22 15:29:00 +00:00
|
|
|
</tp:enumvalue>
|
|
|
|
|
</tp:enum>
|
|
|
|
|
|
2007-09-12 16:23:53 +00:00
|
|
|
</interface>
|
|
|
|
|
</node>
|
