Setting tunnel IP address fails on German Windows 7

[David Woodhouse]

On Thu, 2015-08-06 at 10:55 +0200, Nikos Mavrogiannopoulos wrote:
> On Wed, Aug 5, 2015 at 5:23 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> > > https://github.com/nmav/openconnect-mine/commits/my-changes
> > > I carry these patches independently in epel7, openwrt and fedora.
> > > Would be nice if they become part of openconnect.
> > Those all look fine apart from the top one. I don't like passing extra
> > stuff in via stdin like that. If you're using this for form answers,
> > hoping that they'll be in the right order, then I'd be *much* happier
> > with providing those answers in a form like the one NetworkManager uses
> > to store them — with form and element name, looking something like:
> >    form.main.username=dwmw2
> 
> I don't see how could that work. Note that this is about the command
> line client. How would a caller find out the form names, and how would
> then provide these formatted strings to the client?
> 
> The use case I wanted to handle in openwrt is having two passwords
> with the second password being fixed (the rationale was at
> http://lists.infradead.org/pipermail/openconnect-devel/2015-June/003037.html
> )

I'd rather have something that can solve the *general* use case. And be
a little bit more robust in the case where the second input you get
asked for *isn't* the one you expected.

You could have a mode where the command line client prints the
form/item names when it's requesting input. Or even a --dump-form-input
mode where it just spits them all out after a successful
authentication, in the syntax that it'll accept back again.

It's not hard to provide them back to the client — a series of
--form-response= options, which can also come from a config file (which
we parse the same as command-line options these days).

It also wouldn't be *that* hard to make a fully capable authentication
UI that works with luci. I know luci can't do long-running processes
but it doesn't need to. You can spawn a separate client which uses
libopenconnect but just opens a local UNIX socket for its "user
interaction".

Then a luci page could get the currently-outstanding form from that
UNIX socket and render it. And when the web client POSTs some answers,
it can spit those into the waiting UNIX socket. All the answers can
(optionally) be remembered and go into the network configuration. And
in fact you can also have a mode where the answers *aren't* recorded,
and the user needs to manually authenticate to the VPN each time.


-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150806/6a15848e/attachment.bin>