Hi,
> -Original Message-
> From: Lev Stipakov [mailto:lstipa...@gmail.com]
> Sent: Thursday, November 7, 2019 6:45 PM
> To: openvpn-devel@lists.sourceforge.net
> Cc: Lev Stipakov
> Subject: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun
> device
>
> +const static GUID GU
Hi,
On Thu, Nov 7, 2019 at 12:49 PM Lev Stipakov wrote:
> From: Lev Stipakov
>
> To open wintun device, we cannot use "\\.\Global\Wintun"
> path as before. To get device path which we supply to CreateFile,
> we have to use SetupAPI to:
>
> - enumerate network adapters with "wintun" as componen
Hi,
Doesn't this mean that if --dev-node is specified, we'll open tapwindows
> adapter
> with that name even if "--window-driver wintun" is specified? The open may
> succeed
> but subsequent wintun-specific processing will fail.
>
--dev-node is not (yet) supported and open will fail (just re-te
Hi,
On Tue, Nov 19, 2019 at 3:50 AM Lev Stipakov wrote:
> Hi,
>
> Doesn't this mean that if --dev-node is specified, we'll open tapwindows
>> adapter
>> with that name even if "--window-driver wintun" is specified? The open
>> may succeed
>> but subsequent wintun-specific processing will fail.
Hi,
Apart from the error message, there is a larger issue especially when we
> use iservice. In that case, we have to preserve privilege separation and
> allowing a user to open a device handle in use by another has to be avoided.
>
Do you see it as a security issue when handle can be opened by a
Hi Lev,
On Tue, Nov 19, 2019 at 12:23 PM Lev Stipakov wrote:
> Hi,
>
> Apart from the error message, there is a larger issue especially when we
>> use iservice. In that case, we have to preserve privilege separation and
>> allowing a user to open a device handle in use by another has to be avoid
irst available adapter"
approach to Wintun adapters.
Best regards,
Simon
From: Selva Nair
Sent: Tuesday, November 19, 2019 7:03 PM
To: Lev Stipakov
Cc: Lev Stipakov ; openvpn-devel
Subject: Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun
device
Hi Lev,
Hi,
> We have more options here:
>
Can we combine B and C?
1) During installation, we create one adapter, as we do now.
2) On connection we enumerate adapters and pick the first one which is not
connected.
3) If we could not find free adapter (another VPN connection is already
running), we cr
Hi,
(cc:ed to -devel)
> I would vote for B and not the combination.
>
> With wintun there is no backwards compatibility requirements, so we could
> use a cleaner, consistent and simpler approach (i.e B). Do not create any
> adapter during installation and dynamically create a temporary adapter a
line know what
they're doing.
Best regards,
Simon
From: Lev Stipakov
Sent: Monday, November 25, 2019 10:04 AM
To: Selva Nair
Cc: openvpn-devel
Subject: Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun
device
Hi,
(cc:ed to -devel)
I would vot
Hi
On Mon, Nov 25, 2019 at 4:03 AM Lev Stipakov wrote:
> Hi,
>
> (cc:ed to -devel)
>
>
>> I would vote for B and not the combination.
>>
>> With wintun there is no backwards compatibility requirements, so we could
>> use a cleaner, consistent and simpler approach (i.e B). Do not create any
>> ad
Hi,
On Mon, Nov 25, 2019 at 09:44:19AM +, Simon Rozman wrote:
> 1.if adapter "My VPN Connection" doesn't exist, create it.
> 2.else enable it
> 3.use it
> 4.disable it
> An annoyance here is, the adapters pile up over time. On multi-user
> computers, OpenVPN GUI don't have a
12 matches
Mail list logo