Hi,

On Mon, Jan 22, 2018 at 12:18 PM, David Sommerseth
<open...@sf.lists.topphemmelig.net> wrote:
> On 22/01/18 16:27, Selva Nair wrote:
>> - Present patch: connection process appears stuck (but UI is still
>> responsive) and logs show the daemon is waiting for signature
>>
>> - This proposal: connection fails with: "External EC cert/key not
>> supported in this config. Try using --management-external-key 2"
>> User edits the config option and the connection process appears stuck .....
>>
>> I suppose the latter is a bit better.
>
> Well, it should probably be tweaked slightly better.  First of all, if run via
> a GUI front-end, it's the GUI which should set this argument.  We could
> consider to add a "fail-safe" on this option, so once set - it can't be
> changed again.  The more advanced rabbit whole fix would be that the command
> line provided --management-external-key option overrides whatever is in the
> configuration file; doing this will require more work though.

Problem with GUI specifying the option is that it has to first check
whether the config uses management-external-key (this option
interferes with --key, --pkcs12 etc.). Probably not an issue with most
UI's out there but Windows GUI doesn't currently parse the config at
all. That said, Windows GUI doesn't support management-external-key so
that's not a strong argument.

>
> This will make the VPN connection will still fail, but it won't be stuck any
> more.  The user may complain "but I did add that option!?" which then is a
> better starting point for support cases ... "Yes, it is most likely ignored as
> your user interface is not capable of this feature".
>
> Another alternative is to extend an already longer error log entry, by
> mentioning "also ensure that your management interface front-end supports
> version 2."

What about extending the current "version" command with an argument
where the client states the version of "management-speak" that it
supports. Current management version is 1, we increase it to 1.1 and
unless the client says "version 1.1" or more we do not send PK_SIGN.
The client could do that when it gets the version message or any time
later. The response to version command (current management version and
openvpn daemon's version stays the same). No full-fledged cap
negotiation, but good enough.

The UX would be much better that way.

Selva

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to