According client-options.rst additional argumets ``port`` and ``proto``
are both optional and it's allowed to have port absent and protocol set:
--remote args
Examples:
remote server.example.net tcp
But when protocol is set without preceeding port argument, it is being
misparsed
Hi,
>
> As per setupapi.dev.log, it appears that step 4 (d) is failing with some
> access error to the driver store unless elevated to SYSTEM (see Trac 1321).
> This leaves the adapter not fully configured. Hard to say exactly what fails
> as none of the function calls return any error.
I can
Hi Lev,
Thanks for confirming. What you tested is exactly what I have in mind.
I suppose you tested it using MSVC. I recall when I worked on creating tap
adapters on the fly (patch abandoned for lack of time) some functions in
newdev.dll did not resolve with mingw and I always had to load them on
Hi,
> -Original Message-
> From: Lev Stipakov
> Sent: Wednesday, September 2, 2020 11:37 PM
> To: openvpn-devel@lists.sourceforge.net
> Cc: Lev Stipakov
> Subject: [Openvpn-devel] [PATCH v2] openvpnmsica: make adapter renaming
> non-fatal
>
> From: Lev Stipakov
>
> For some users rena
From: Selva Nair
As reported in Trac 1321, additional adapter instalaltion
by tapctl.exe fails to fully setup the device node (some registry
keys missing, error in setapi.dev.log etc.).
Although the exact cause of this failure is unclear,
letting the Plug and Play subsystem handle the instalaltio
