Setting tunnel IP address fails on German Windows 7

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

 



On Thu, Aug 6, 2015 at 11:57 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
>> 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.

Correct, but the current use case (a second _fixed_ password) doesn't
warrant such a wide change. The current change is pretty safe also, in
the sense that is fully backwards compatible and simple, in the sense
that requires no interaction with the server to set it up. Moreover it
is safe as  it will only read as many lines as provided by stdin (in
openwrt that is a file).

> 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.

That's a paradigm change for the existing code in openwrt and the
use-cases we need to handle currently don't justify that. In fact I
don't see any benefits from such a change. The openwrt interface
allows configuring openconnect (even when the router is offline), for
a non-interactive authentication. Even if we had the resources to
implement that big change, we wouldn't be able to handle use cases
other than that dumb use-case with a second fixed password. So it
feels like you are proposing a very generic framework that requires
too many changes in openconnect and openwrt interface with no visible
advantages for the use-cases handled in openwrt.

regards,
Nikos



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux