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

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

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:

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

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