Hello Guys, sorry for the late reply.

Ok, I'll wait for the fix to retest.

Another question...

Inspecting the wintun interface through the properties I saw that on the
TCP/IPv4 Properties the default option selected is "Use the following IP
address" but the IP address and the Subnet mask were empty. Should that be
a problem?

BR

Rafael

On Tue, Aug 18, 2020 at 5:15 PM Selva Nair <selva.n...@gmail.com> wrote:

> Hi
>
> On Tue, Aug 18, 2020 at 3:42 PM Gert Doering <g...@greenie.muc.de> wrote:
>
>> Hi,
>>
>> On Tue, Aug 18, 2020 at 03:29:19PM -0400, Selva Nair wrote:
>> > > If you already have SYSTEM, accessing wintun from openvpn directly
>> will
>> > > also work and should bring quite a bit of speed improvement.
>> >
>> > I was wrong to assume that this just works. Looking at it again, the
>> current
>> > implementation of wintun support does not seem to cover this. Meaning
>> the
>> > only working approach is to use the interactive service.
>>
>> Indeed, you are right.  Somewhere on the track we lost the ability
>> to do wintun "from OpenVPN" if we *have* SYSTEM.
>>
>> This is the code in tun.c
>>
>>     if (tt->options.msg_channel)
>>     {
>>         ret = service_register_ring_buffers(tt);
>>     }
>>     else
>>     {
>>         msg(M_FATAL, "ERROR:  Wintun requires SYSTEM privileges and
>> therefore "
>>                      "should be used with interactive service. If you
>> want to "
>>                      "use openvpn from command line, you need to do
>> SYSTEM "
>>                      "elevation yourself (for example with psexec).");
>>     }
>>
>>
>> ... so while I'm happy that we got rid of impersonating SYSTEM, the
>> current
>> code does not even try anymore, just assumes "if there is no message
>> channel,
>> we have not enough privileges".
>>
>> OTOH the message is severely misleading now, since it suggests "having
>> the right privileges will make this work".
>>
>>
>> This needs fixing - either we *try*, and if we fail, print the message
>> about insufficient privileges, or we change the message to actually
>> print something like "Wintun support is only possible if the interactive
>> service is used.  Do not run from the CLI.  Use the GUI in non-admin
>> mode.".
>>
>
> We have all the necessary code to do "register ring buffers" that the
> service uses, so just calling it and printing that message on failure
> should fix it.
>
> Looks like something lost by Lev during a rebase or conflict resolution.
>
> Trac #1318
>
> Selva
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to