[PATCH] Re: OpenConnect, Juniper and NetworkManager

[David Woodhouse]

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 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/20160510/13b4d714/attachment.bin>