On Mon, 2016-05-09 at 16:44 -0600, Brett Johnson wrote:
On Mon, 2016-05-09 at 09:02 +0100, David Woodhouse wrote: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.
I'm missing the context for this, as I could only find the previous patch submission messsage on openconnect-devel (and I'm only subscribed to networkmanager-list). Is Ian providing patches for the networkmanager- openconnect plugin, so that it supports --juniper mode? If so, that's awesome :).
Yes. I basically quoted the whole of his message, so you're not really missing much context. The openconnect-devel message is here, if you want it: http://lists.infradead.org/pipermail/openconnect-devel/2016-May/003652.html
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 :)<raises hand>. I use openconnect on the command line, and would love to test patches that integrate it into NM, assuming that's what we're talking about here. So I'll volunteer :)
The latter part of the paragraph is actually talking about something different. Juniper / Junos Pulse is transitioning from the old "Network Connect" protocol, to the new "Junos Pulse" protocol. Both of which I might be using non-official names for. The old NC protocol is fairly horrid and supports only Legacy IP, and it's what I've got support for in OpenConnect. The new protocol is somewhat less horrid, and supports IPv6 too, *and* the authentication is... well, differently horrid. It's mostly EAP- based. But it does have a fallback to "just spawn a web browser", which leaves us with the same problem as the NC protocol. I understand it (or did, last time I was paying attention), but don't yet have support implemented in OpenConnect. It's a volunteer for *this* that I was hoping for (perhaps naïvely). The problem in both cases is that we are expected to render and have the user interact with arbitrary HTML (+JS) pages. In OpenConnect I've got some hackish special-case parsing code that understands the *most* common authentication pages — the ones that are basically unchanged from Juniper's templates. But if anything changes, it doesn't work. That's why I'd *really* like the NetworkManager GUI to have a proper HTML renderer, instead of using the pre-parsed output of my special- case hacks to present a GUI to the user.
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?
Again, without any context, it's hard to tell what Ian's original code/patches look like, but having two separate plugin names seems like it'd solve the UI problem. The current plugin says "Cisco AnyConnect Compatibe VPN(openconnect)". It seems consistent to also have a "Juniper NetConnect VPN(openconnect)" (or something like that) entry.
Right. That's what I'm asking for... and that's the main reason I Cc'd this list, to solicit ideas on how best to do it. -- David Woodhouse Open Source Technology Centre David Woodhouse intel com Intel Corporation
Attachment:
smime.p7s
Description: S/MIME cryptographic signature