Re: [PATCH] Re: OpenConnect, Juniper and NetworkManager

[Ian Turner <vectro vectro org>]

On 05/09/2016 04:02 AM, David Woodhouse wrote:
> Thanks for looking at this. I'm still slightly concerned about exposing
> this to users in its current form — I'd like to pass the HTML directly
> for rendering, instead of using our half-baked parser which can only
> handle the trivial common cases in the Juniper example forms.
I agree this approach is a better way; but unfortunately it's also more
than I'm willing to bite off. Sorry.
> Could we drop the boolean NM_OPENCONNECT_KEY_JUNIPER_MODE and just have
> a string key that contains exactly the string that's passed to
> openconnect_set_protocol(), please?
The problem is that while the authentication piece uses the OpenConnect
library, NetworkManager itself kicks off openconnect via the command
line (see the change to nm_openconnect_start_openconnect_binary). So
unless you are prepared to change the OpenConnect command line to take a
parameter like --vpn-type, NetworkManager will need to know some details
about the type of VPN.
> And if it's absent/empty then we do
> nothing and hence default to AnyConnect. That makes it nice and generic
> and easier to support other VPN protocols in future. We do have at
> *least* Junos Pulse in the works — I have it decoded, and just need to
> find the time and motivation to hook up all the EAP nonsense. Or
> preferably a willing volunteer who actually *uses* it :)
I can test Junos Pulse as well.
> Can we make this appear to NetworkManager as two *separate* plugins,
> that just happen to use (mostly) the same binaries? The properties
> plugin does have the name hard-coded so it can't be *entirely* the same
> binaries... but see GNOME bug #765732 where the GTK parts are all taken
> out into a *separately* loaded library anyway, so that can still be
> shared while the plugin itself is built for both Juniper and
> AnyConnect, returning different values for PROP_NAME/PROP_DESC?
Yes, I'm happy to take a crack at this.

--Ian