Hi,
On 10/06/19 19:25, Selva Nair wrote:
On Mon, Jun 10, 2019 at 4:50 AM Samuli Seppänen <sam...@openvpn.net> wrote:
Il 07/06/19 20:19, Selva Nair ha scritto:
Hi JJK,
On Fri, Jun 7, 2019 at 11:09 AM Jan Just Keijser <janj...@nikhef.nl> wrote:
hi all,
in the eduVPN project we've run into a strange issue:
HP Envy laptops running Windows 10 have a "handy" feature to
automatically switch from wifi to a 'wired' adapter if one is detected.
The use case behind this is that if you put your laptop in a docking
station (with LAN) it will auto-switch to it.
How does this relate to OpenVPN: when an OpenVPN connection is
established, the HP Envy driver gimmick detects the tap-windows device
as a LAN adapter and switches off wifi -regardless of whether you are on
a LAN or not. Thus, "plain" OpenVPN 2.4 becomes quite hard to use on
these laptops.
Now the strange part is, that both Viscosity and NordVPN - each with
their own tap-win adapters do NOT have this problem.
So my question now is: what could be causing this and how can we
resolve it.
The patches the Viscosity folks made to the tap-win driver for their
setup are in github (pull request #47, IIRC) and I don't see anything
truly strange in that patch.
The only thing that seems to be different is whether a device is
sporting the UI flag in the "characterstics" section.
Does anybody have a clue how to best approach this?
One thing I've noticed is that in the driver inf file viscosity has set
characteristics = 0x1 ; NCF_VIRTUAL
It goes into the registry entries for the device node.
They don't seem to have a link to download the patched source (have to
make a request by email -- no idea whether a paid license is also
required), so I haven't looked for any other changes in the sources.
Possibly you could ask for the source code and do a diff.
Selva
Hi,
This is tangential, but I wonder if these "characteristics" (also) have
an effect on which HLK tests are required? Rozmansi's "Introduce TAP
adapter as a virtual device" does not touch them:
https://github.com/OpenVPN/tap-windows6/pull/84/files
That PR, as-is, did not help narrow down the scope of HLK tests.
The wintun driver has this in characteristics:
wintun.inf:Characteristics = 0x1 ; NCF_VIRTUAL
Default tap-windows6 has
version.m4:define([PRODUCT_TAP_WIN_CHARACTERISTICS], [0x81])
Thoughts?
Interesting --- that should get into the inf file, but on my machine inf has
[tap0901.ndi]
CopyFiles = tap0901.driver, tap0901.files
AddReg = tap0901.reg
AddReg = tap0901.params.reg
Characteristics =
*IfType = 0x6 ; IF_TYPE_ETHERNET_CSMACD
*MediaType = 0x0 ; NdisMedium802_3
*PhysicalMediaType = 14 ; NdisPhysicalMedium802_3
Note that Characteristics is blank as if @PRODUCT_TAP_WIN_CHARACTERISTICS@
did not get expanded. . Do I have a wrong .inf?
By the way, 0x81 stands for NCF_VIRTUAL|NCF_HAS_UI
No idea what difference it may make to HLK or anything else.
for the record: we've done tests with a modified .INF file and we've
set the characteristics to 0x01 in the registry , but to no avail - the
wifi connection is still shut down when the tunnel comes up.
JJK
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
