Hello, I beleive that people will ignore "not green" status. I think
there're should be an option of treating that situation as fatal error.
However, I agree that it requires help from core
20 сент. 2017 г. 8:39 ПП пользователь "Selva" <selva.n...@gmail.com>
написал:
> 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#issuecomm
>>> ent-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
>
>
------------------------------------------------------------------------------
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
