Stared-at-code ("looks reasonable"). Getting rid of netsh.exe calls is
a good thing.
Actually tested! MinGW builds, on a Win10 system, running openvpn.exe
from a "cmd.exe run as administrator" window, so no iservice involved -
OpenVPN tells me "IPv6 route added using ipapi", and "route print -6"
I've stared at the code for a bit ("git show -w" helps), but not having
deep understanding of all windows/management intricacies, I can only say
"it looks reasonable".
I have also built a test binary (Ubuntu/MinGW) which behaved properly when
called from the CLI. Tested F1, F2, F3, F4 and ctrl-C.
Hi
which actually brings up the observation that there's netsh.exe calls
> left, "netsh.exe interface ipv6 set address 2 2001:608:..." :-) )
>
Yes, it's on my radar :)
Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lis
I've stared at the code for quite a bit, and this looks good, and
cleans up quite a few of the odd corner cases ("do not set signal
if some other signal is there already") that have grown over time,
like the one in proxy.c.
I have not manually tested this to see if I could break it, or reproduce
o
Hi,
On Mon, Jan 02, 2023 at 02:43:22PM -0500, selva.n...@gmail.com wrote:
> From: Selva Nair
>
> Currently we use the old signal API which follows system-V or
> BSD semantics depending on the platform and/or feature-set macros.
> Further, signal has many weaknesses which makes proper masking
> (
I reviewed v1, checked that true/false has been replaced with 0/1/2.
Checked that the only change in v2 is that "succeeded/skipped" is
replaced with "succeeded".
Compiled and tested, looks good.
Acked-by: Lev Stipakov
___
Openvpn-devel mailing list
O
