On Fri, 2016-02-26 at 16:16 -0600, Dan Williams wrote:
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://bugzilla.redhat.com/show_bug.cgi?id=1298732
lgtm. Merged master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=abc700c5c71f474730f703c648b0b8dab455d7ba nm-1-0: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=ba7359441b565c5ac6b0524b6aa04b155f0a9123 Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part