Otherwise NetworkManager can be too fast calling a method:
<error> [1461073999.2362] vpn-connection[0x7fe39ec491e0,be049803-a705-438f-b8f5-49db87640c93,"libreswan",0]:
plugin NeedSecrets request #1 failed: No such interface 'org.freedesktop.NetworkManager.VPN.Plugin'
on object at path /org/freedesktop/NetworkManager/VPN/Plugin
When we receive a connection from NetworkManager it is not guaranteed
that the connection verifies. For example, if the current libnm version
is older then the NetworkManager version.
Be more accepting and don't do any verification of the connection.
For NMVpnPluginOld this change is uncritical, because there are probably
no users of this API anyway.
NMVpnServicePlugin is new API since nm-1-1. However, this API is already
strongly used by all the plugins we ported over. So this change is
affecting them.
This should only matter if libnm's and NetworkManager's version differ,
because NetworkManager just doesn't send out an invalid connection. It
actually only matters if NetworkManager is a newer version and sends an
invalid connection to the client. That is anyway badly tested and probably
this changes rather improves compatibility than breaking existing users.
GError codes are only unique per domain, so logging the code without
also indicating the domain is not helpful. And anyway, if the error
messages are not distinctive enough to tell the whole story then we
should fix the error messages.
Based-on-patch-by: Dan Winship <danw@gnome.org>
If the plugin supports interactive mode, but the VPN binary (like vpnc
or openvpn) doesn't support it, then the plugin should return
NM_VPN_PLUGIN_ERROR_INTERACTIVE_NOT_SUPPORTED from its connect_interactive()
hook. This lets NetworkManager know to fall back to plain Connect().
Since this notification is done through an error return, the VPN service
plugin code sees the failure and moves the plugin state back to
STOPPED. NetworkManager sees that state change, and terminates the
connection attempt while waiting for a reply to the Connect() method.
(VPN service plugins that don't support interactive mode at all don't
have this problem because that error is returned before the plugin's
state is moved to STARTING.)
To fix this, do two things:
1) if the connect_interactive() hook fails and returns the error
NM_VPN_PLUGIN_ERROR_INTERACTIVE_NOT_SUPPORTED, postpone the STOPPED
state change for a few seconds to allow NM time to fall back to
plain Connect(). We still want to move the plugin state back to
STOPPED eventually, because otherwise it could stay in STARTING
forever.
2) change state to STARTING only if the connect/connect_interactive
plugin hooks were successful. Otherwise the plugin would still be
in STARTING state, and it's not valid to call Connect()/ConnectInteractive()
during the STARTING state.
https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00091.htmlhttps://bugzilla.redhat.com/show_bug.cgi?id=1298732
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
- "gsystem-local-alloc.h" and <gio/gio.h> are already included via
"nm-default.h". No need to include them separately.
- include "nm-macros-internal.h" via "nm-default.h" and drop all
explict includes.
- in the modified files, ensure that we always include "config.h"
and "nm-default.h" first. As second, include the header file
for the current source file (if applicable). Then follow external
includes and finally internal nm includes.
- include nm headers inside source code files with quotes
- internal header files don't need to include default headers.
They can savely assume that "nm-default.h" is already included
and with it glib, nm-glib.h, nm-macros-internal.h, etc.
The plugins set state only on failures and often forget to do that. Do the
correct status transition to STOPPED in nm_vpn_service_plugin_failure() instead.
The get_state() is only used to find out whether to fail or orderly disconnect
depending on whether we're STARTING or already STARTED. Handle that in
nm_vpn_service_plugin_disconnect() in a generic manner instead.
Make it possible to construct the plugin instance in a way that disconnects the
connection if the DBus client that activated it drops off the bus. This makes the
plugins conveniently clean up when NetworkManager crashes.
We need this, as with multiple VPN support we can loose track of the client bus
names when the daemon crashes leaving to nice way to clean up on respawn.
However, this behavior is not desired for debugging or hypotetical VPN plugin
users other than NetworkManager (say; "gdbus call -m o.fd.NM.VPN.Plugin.Connect").
Let the plugin decide when to use it.
We now (since 3272ff6 libnm/libnm-glib: don't quit in the middle of asking for
secrets) always hook on the quit timer when NM asks the plugin if it needs
secrets. The timer is 20 seconds, which seems too short.
Let's make it three minutes. Don't bother adding another timer or using a
distinct timeout: it does no harm for the plugin to remain unused for three
minutes on a bus.
Another option would be to completely unhook it; however the plugin wouldn't
learn if the user cancelled the NM's secrets request and would remain unused
on the bus forever.
The localization headers are now included via "nm-default.h".
Also fixes several places, where we wrongly included <glib/gi18n-lib.h>
instead of <glib/gi18n.h>. For example under "clients/" directory.
After copying "nm-vpn-plugin-old.*" to "nm-vpn-service-plugin.*",
rename the class and add it to the Makefile.
This will become the new VPN Service API for libnm 1.2. No changes
done yet except renaming of the classes and functions.
Rename the previous classes NMVpnPlugin(Old) to NMVpnServicePlugin
to have a distinct name from NMVpnEditorPlugin. Buth are plugins, but
with a different use.
https://bugzilla.gnome.org/show_bug.cgi?id=749951
Files are yet unchanged, only copy them to get a nicer history.
/bin/cp libnm/nm-vpn-plugin-old.c libnm/nm-vpn-service-plugin.c
/bin/cp libnm/nm-vpn-plugin-old.h libnm/nm-vpn-service-plugin.h
