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

On Sun, 2016-05-15 at 13:23 -0400, Ian Turner wrote:
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.

Understood. I'm more mentioning it to explain my reticence about
exposing Juniper mode in NetworkManager. But I think the time has come
to do it (NM support) anyway, incomplete though it is. It does work for
a lot of people already.

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.

Good point. I've added a --protocol option on the command line:

We can still special-case "nc" → "--juniper" in nm-openconnect-service
for now, to avoid *requiring* the new version. But before adding any
new protocols (i.e. Pulse) we'll add a proper way of querying which
protocols are supported, and make sure we use --protocol in future.

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.

Yeah, someone just needs to write the support. Perhaps I should list it
as a GSoC project for next year...

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.

Great, Thanks!


Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]