[PATCH] Re: OpenConnect, Juniper and NetworkManager

[David Woodhouse]

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:
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/67ba82a

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!

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20160516/ee10f5e8/attachment.bin>