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