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
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
>>
ds,
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 vote for B and not the combination.
W
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
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
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,
On Tue, Nov 1
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
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
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
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
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
&g
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 component id
- for each adapter save its guid
- open device information set
12 matches
Mail list logo
