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



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 intel com                              Intel Corporation

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



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