Hi,
On Thu, Sep 14, 2017 at 3:21 PM, Selva <selva.n...@gmail.com> wrote:
> Hi,
>
> Quoting from the meeting logs:
>
>
>> Discussed having more fine-grained signalling from OpenVPN to OpenVPN
>> GUI. The lack of clear signals from OpenVPN to OpenVPN GUI has been a
>> rather common problem:
>>
>
>
>> <https://github.com/OpenVPN/openvpn-gui/issues/168#issuecomment-305243166
>> >
>> <https://github.com/OpenVPN/openvpn-gui/issues/9>
>> <https://github.com/OpenVPN/openvpn-gui/issues/183>
>>
>
>
>> This problem is probably not limited to OpenVPN GUI (Windows), but also
>> affects other GUI's like NetworkManager. It was agreed that the best
>> approach is that Selva, mattock and others involved on the Windows side
>> come up with a PoC or "RFC" of how this issue could be tackled ...
>> OpenVPN core will then be modified if necessary.
>
>
> No time to write an "RFC" or such for something of this sort, but here are
> some comments/suggestions:
>
> 0. Do not send a status message that reads "CONNECTED, SUCCESS" to the
> management when there has been critical errors such as: failed to add
> routes or to set ipv6 address using the service or to talk to the service,
> etc.. Send something like "CONNECTED,ERROR".
>
> A status signalling with more fine-grained info to the management would be
> helpful, but as a short-term fix, just changing SUCCESS to ERROR in some
> cases may be a good start.
>
> 1. Mark all messages to the management as I (for info), W (for warning), N
> (for non fatal error) etc. -- on some log lines this info is currently
> missing. I think, part of the problem is not all messages are printed with
> an M_xx flag.
>
> 2. Mark non-fatal opevpn_execve errors as M_NONFATAL instead of M_WARN
>
> 3. Treat failure to talk to the service (when msg_channnel is defined) as
> M_NONFATAL not M_WARN
>
> 4. Mark route add/del errors via service as M_NONFATAL -- currently
> M_WARN.
> Mark route addition failure by other means as M_NONFATAL -- currently
> M_WARN on all platforms, and all methods, I think.
>
> 5. Mark "ifconfig" (set address) errors as consistently M_FATAL or
> M_NONFATAL (see comment on "fatality" below).
> Currently these are M_WARN if done by service, M_FATAL otherwise.
>
> Given that M_FATAL should be used only very rarely, if at all --- e.g., if
> proceeding further makes no sense --- most errors should be M_NONFATAL.
> The above comments reflect that sentiment.
>
> That said, whether address and route addition errors should be FATAL
> deserves some discussion -- In case of address addition, an error probably
> has to be FATAL, but "route add" failures are borderline cases. E.g., if
> "--redirect-gateway" fails, the tunnel may be considered meaningless in
> many use cases and thus a fatal error. So, some but not all route-add
> errors may have to be treated as FATAL.
>
> If there is consensus, and an appetite for patch review, I can send in
> some patches for 2 to 5 and possibly 1. For 0, I'm not sure how to keep
> track of past errors to construct a useful status message.
>
> Thanks,
>
Any feedback on how to go about these ? I want to make the GUI not show
green when there are route errors, but need some co-operation from the
core..
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
