2016-04-04 23:09:48 +00:00
<?xml version="1.0" encoding="UTF-8"?>
<node name= "/" >
2007-09-12 16:23:53 +00:00
2016-04-04 23:09:48 +00:00
<!--
org.freedesktop.NetworkManager.VPN.Plugin:
2022-03-18 14:52:48 +00:00
@short_description: VPN Service.
2016-04-04 23:09:48 +00:00
This interface is provided by plugins providing VPN services to the
NetworkManager daemon.
-->
2007-09-12 16:23:53 +00:00
<interface name= "org.freedesktop.NetworkManager.VPN.Plugin" >
2014-09-10 17:51:53 +00:00
<annotation name= "org.gtk.GDBus.C.Name" value= "VpnPlugin" />
2016-04-04 23:09:48 +00:00
<!--
Connect:
@connection: Describes the connection to be established.
2013-06-18 14:32:53 +00:00
2016-04-04 23:09:48 +00:00
Tells the plugin to connect. Interactive secrets requests (eg, emitting
2013-06-18 14:32:53 +00:00
the SecretsRequired signal) are not allowed.
2016-04-04 23:09:48 +00:00
-->
<method name= "Connect" >
2007-09-12 16:23:53 +00:00
<annotation name= "org.freedesktop.DBus.GLib.CSymbol" value= "impl_vpn_plugin_connect" />
2016-04-04 23:09:48 +00:00
<arg name= "connection" type= "a{sa{sv}}" direction= "in" />
2013-06-18 14:32:53 +00:00
</method>
2016-04-04 23:09:48 +00:00
<!--
ConnectInteractive:
@connection: Describes the connection to be established.
@details: Additional details about the Connect process.
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).
-->
2013-06-18 14:32:53 +00:00
<method name= "ConnectInteractive" >
<annotation name= "org.freedesktop.DBus.GLib.CSymbol" value= "impl_vpn_plugin_connect_interactive" />
2016-04-04 23:09:48 +00:00
<arg name= "connection" type= "a{sa{sv}}" direction= "in" />
<arg name= "details" type= "a{sv}" direction= "in" />
2007-09-12 16:23:53 +00:00
</method>
2016-04-04 23:09:48 +00:00
<!--
NeedSecrets:
@settings: Describes the connection that may need secrets.
@setting_name: The setting name within the provided connection that requires secrets, if any.
Asks the plugin whether the provided connection will require secrets to
connect successfully.
-->
2007-09-27 02:20:53 +00:00
<method name= "NeedSecrets" >
<annotation name= "org.freedesktop.DBus.GLib.CSymbol" value= "impl_vpn_plugin_need_secrets" />
2016-04-04 23:09:48 +00:00
<arg name= "settings" type= "a{sa{sv}}" direction= "in" />
<arg name= "setting_name" type= "s" direction= "out" />
2007-09-27 02:20:53 +00:00
</method>
2016-04-04 23:09:48 +00:00
<!--
Disconnect:
2008-02-28 02:07:21 +00:00
Disconnect the plugin.
2016-04-04 23:09:48 +00:00
-->
<method name= "Disconnect" >
2007-09-12 16:23:53 +00:00
<annotation name= "org.freedesktop.DBus.GLib.CSymbol" value= "impl_vpn_plugin_disconnect" />
</method>
2016-04-04 23:09:48 +00:00
<!--
SetConfig:
@config: Generic configuration details for the connection.
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 19:50:07 +00:00
Set generic connection details on the connection.
2016-04-04 23:09:48 +00:00
-->
<method name= "SetConfig" >
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 19:50:07 +00:00
<annotation name= "org.freedesktop.DBus.GLib.CSymbol" value= "impl_vpn_plugin_set_config" />
2016-04-04 23:09:48 +00:00
<arg name= "config" type= "a{sv}" direction= "in" />
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 19:50:07 +00:00
</method>
2016-04-04 23:09:48 +00:00
<!--
SetIp4Config:
@config: Ip4Config details for the connection. You must call SetConfig() before calling this.
2008-02-28 02:07:21 +00:00
Set IPv4 details on the connection.
2016-04-04 23:09:48 +00:00
-->
<method name= "SetIp4Config" >
2007-09-12 16:23:53 +00:00
<annotation name= "org.freedesktop.DBus.GLib.CSymbol" value= "impl_vpn_plugin_set_ip4_config" />
2016-04-04 23:09:48 +00:00
<arg name= "config" type= "a{sv}" direction= "in" />
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 19:50:07 +00:00
</method>
2016-04-04 23:09:48 +00:00
<!--
SetIp6Config:
@config: Ip6Config details for the connection. You must call SetConfig() before calling this.
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 19:50:07 +00:00
Set IPv6 details on the connection.
2016-04-04 23:09:48 +00:00
-->
<method name= "SetIp6Config" >
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 19:50:07 +00:00
<annotation name= "org.freedesktop.DBus.GLib.CSymbol" value= "impl_vpn_plugin_set_ip6_config" />
2016-04-04 23:09:48 +00:00
<arg name= "config" type= "a{sv}" direction= "in" />
2007-09-12 16:23:53 +00:00
</method>
2016-04-04 23:09:48 +00:00
<!--
SetFailure:
@reason: The reason for the failure.
2008-02-28 02:07:21 +00:00
Indicate a failure to the plugin.
2016-04-04 23:09:48 +00:00
-->
<method name= "SetFailure" >
2007-09-12 16:23:53 +00:00
<annotation name= "org.freedesktop.DBus.GLib.CSymbol" value= "impl_vpn_plugin_set_failure" />
2016-04-04 23:09:48 +00:00
<arg name= "reason" type= "s" direction= "in" />
2007-09-12 16:23:53 +00:00
</method>
2016-04-04 23:09:48 +00:00
<!--
State:
2008-02-28 02:07:21 +00:00
The state of the plugin.
2007-09-12 16:23:53 +00:00
2016-04-04 23:02:00 +00:00
Returns: <link linkend= "NMVpnServiceState" > NMVpnServiceState</link>
2016-04-04 23:09:48 +00:00
-->
<property name= "State" type= "u" access= "read" />
<!--
StateChanged:
2016-04-04 23:02:00 +00:00
@state: (<link linkend= "NMVpnServiceState" > NMVpnServiceState</link> ) The new state of the plugin.
2016-04-04 23:09:48 +00:00
2008-02-28 02:07:21 +00:00
Emitted when the plugin state changes.
2016-04-04 23:09:48 +00:00
-->
<signal name= "StateChanged" >
<arg name= "state" type= "u" />
2007-09-12 16:23:53 +00:00
</signal>
2016-04-04 23:09:48 +00:00
<!--
SecretsRequired:
@message: 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.
@secrets: 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.
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.
-->
2013-06-18 14:32:53 +00:00
<signal name= "SecretsRequired" >
2016-04-04 23:09:48 +00:00
<arg name= "message" type= "s" direction= "out" />
<arg name= "secrets" type= "as" direction= "out" />
2013-06-18 14:32:53 +00:00
</signal>
2016-04-04 23:09:48 +00:00
<!--
NewSecrets:
@connection: Describes the connection including the new secrets.
2013-06-18 14:32:53 +00:00
Called in response to a SecretsRequired signal to deliver updated secrets
or other information to the plugin.
2016-04-04 23:09:48 +00:00
-->
<method name= "NewSecrets" >
2013-06-18 14:32:53 +00:00
<annotation name= "org.freedesktop.DBus.GLib.CSymbol" value= "impl_vpn_plugin_new_secrets" />
2016-04-04 23:09:48 +00:00
<arg name= "connection" type= "a{sa{sv}}" direction= "in" />
2013-06-18 14:32:53 +00:00
</method>
2016-04-04 23:09:48 +00:00
<!--
Config:
@config: The configuration information.
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 19:50:07 +00:00
The plugin obtained generic configuration information.
2016-04-04 23:09:48 +00:00
-->
<signal name= "Config" >
<arg name= "config" type= "a{sv}" />
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 19:50:07 +00:00
</signal>
2016-04-04 23:09:48 +00:00
<!--
Ip4Config:
@ip4config: The IPv4 configuration.
2008-02-28 02:07:21 +00:00
The plugin obtained an IPv4 configuration.
2016-04-04 23:09:48 +00:00
-->
<signal name= "Ip4Config" >
<arg name= "ip4config" type= "a{sv}" />
2007-09-12 16:23:53 +00:00
</signal>
2016-04-04 23:09:48 +00:00
<!--
Ip6Config:
@ip6config: The IPv6 configuration.
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 19:50:07 +00:00
The plugin obtained an IPv6 configuration.
2016-04-04 23:09:48 +00:00
-->
<signal name= "Ip6Config" >
<arg name= "ip6config" type= "a{sv}" />
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 19:50:07 +00:00
</signal>
2016-04-04 23:09:48 +00:00
<!--
LoginBanner:
@banner: The login banner string.
2008-02-28 02:07:21 +00:00
Emitted when the plugin receives a login banner from the VPN service.
2016-04-04 23:09:48 +00:00
-->
<signal name= "LoginBanner" >
<arg name= "banner" type= "s" />
2007-09-12 16:23:53 +00:00
</signal>
2016-04-04 23:09:48 +00:00
<!--
Failure:
2016-04-04 23:02:00 +00:00
@reason: (<link linkend= "NMVpnPluginFailure" > NMVpnPluginFailure</link> ) Reason code for the failure.
2016-04-04 23:09:48 +00:00
2008-02-28 02:07:21 +00:00
Emitted when a failure in the VPN plugin occurs.
2016-04-04 23:09:48 +00:00
-->
<signal name= "Failure" >
<arg name= "reason" type= "u" />
2007-09-12 16:23:53 +00:00
</signal>
2021-05-12 16:18:57 +00:00
2007-09-12 16:23:53 +00:00
</interface>
</node>