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
>> ad
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,
(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
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
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 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
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,
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,
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 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,
> -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
13 matches
Mail list logo
