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>
