Hi, On Mon, Jan 22, 2018 at 12:31 PM, Selva Nair <selva.n...@gmail.com> wrote: > 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.
I would appreciate some feedback. Thanks, 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
