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,
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
