[PATCH] Re: OpenConnect, Juniper and NetworkManager
David Woodhouse
dwmw2 at infradead.org
Mon May 9 01:02:16 PDT 2016
On Sun, 2016-05-08 at 18:36 -0400, Ian Turner wrote:
> OK, patches attached. Feedback welcome; if the response here is
> positive (or silent), then I will go ahead and submit to GNOME and
> KDE.
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.
But I suppose it's been a while and we still don't have it, and for a
lot of people this is better than nothing. Running openconnect on the
command line without NetworkManager's knowledge is a pain. So maybe I
should just accept it as-is :)
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? 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 :)
We should also think about the user experience with your patches, when
configuring a new VPN connection. They go to add a new VPN, and have to
select 'Cisco AnyConnect compatible (openconnect)' from the list of VPN
plugins, and *then* flip this switch to Juniper mode.
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?
Or maybe there's a better way? Let's add the NM list to Cc...
--
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
-------------- 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/20160509/6b1abd69/attachment-0001.bin>
More information about the openconnect-devel
mailing list