Open nstf-cvb opened 6 years ago
This is still a problem. The NDIS6 driver works really bad under Windows 7 if you apply any load (network traffic) to the system. The NDIS5 driver is much faster and more stable.
As Windows 7 is not supported any more, it is very unlikely that someone will look into this issue.
Yeah. We (Mullvad VPN) have been installing the NDIS5 driver for win7 users all the time because of this issue. In our latest release we upgraded everyone to the latest NDIS6 as a test. This bit us in the ass instantly. Many many users report the app became a lot worse.
So we will go back to conditionally install NDIS5 if the user is on Windows 7 and keep it like that until we stop supporting that OS.
I'm on Windows 7 x64, using commercial anonymous VPN services with OpenVPN, and for a few days I've been trying to track down an issue where every once in a while all packets sent or received from OpenVPN would not be delivered. I was eventually able to find a simple trigger event which reproduces it 100% of the time:
I have also observed it:
It does not occur merely under heavy activity; I can get a pretty good download speed, for example, without an excessive amount of packet loss. I also tested that it is not brought on by high CPU or GPU activity. I tried two different anonymous VPN services, and many different servers within each, with no change. I tried all sorts of MTU-related fixes, even though my MTU appears by testing to be the normal 1472. I tried disabling all security software.
It seems to be triggered by some very particular situation either with a series of packets or some action of the OS which freezes the TAP-Windows thread. Eventually I found this forum thread which describes a similar problem, and as recommended there I downgraded to TAP-Windows NDIS 5. This fixes it. Therefore, it seems to be a bug in Tap-Windows NDIS 6