libnm-glib/libnm/vpn: fix handling of ConnectInteractive() failure (rh #1298732)
authorDan Williams <dcbw@redhat.com>
Fri, 26 Feb 2016 22:16:09 +0000 (16:16 -0600)
committerThomas Haller <thaller@redhat.com>
Wed, 2 Mar 2016 10:27:17 +0000 (11:27 +0100)
commitabc700c5c71f474730f703c648b0b8dab455d7ba
tree14358a778ab35e0b749787c01109143231221710
parent4fb8cf35f46d69fe31ec61e86576e5c0ba661d96
libnm-glib/libnm/vpn: fix handling of ConnectInteractive() failure (rh #1298732)

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.html
https://bugzilla.redhat.com/show_bug.cgi?id=1298732
libnm-glib/nm-vpn-plugin.c
libnm/nm-vpn-plugin-old.c
libnm/nm-vpn-service-plugin.c