I think I have solved this problem. I'm a network administrator so I'm used to dealing with weird problems like this. I have been running a torrent program for 12 hours now with no dropouts at all, I downloaded 3 gig of files. This went up to the maximum upload speed with no problems. Before this it would disconnect every few minutes. I went through most of these fixes with pia, I gave up on them as none seemed to work and came here then found the same problem. Here is my theory of what the problem really is, and why some of these fixes help a little.
One clue was how the torrent tornado program didn't cause disconnections so the issue seems to be in uploads only. Another was in a forum where they said the router can grind the traffic to a halt so it stops completely. Also the tap adapter seems to get stuck, it can be freed by disabling it and then reenabling it. It relates to the openvpn driver, a message comes on that it is still running when this happens.
The problem seems to be the tap adapter driver times out and closes, then when a session tries to reconnect it can't find the tap adapter. The openvpn driver still has some data so it doesn't close, it keeps trying to connect to the tap adapter. This might be caused by the router getting congested, there could be no packets going through so the tap adapter closes. Another possibility is some buffers get full, you can increase the size of the buffers in the arirvpn preferences which may help this. My guess is airvpn tries to reconnect to the old session to resend the packets it still has, this is impossible because the TAP adapter has closed that session in a timeout. This is likely because UDP packets would be lost if discarded resulting in data being corrupted, I doubt the program would act different with the UDP and TCP settings. It can't restart the TAP adapter without losing some packets so it gets caught in a loop.
The reason that changing settings in an antivirus helps is that the congestion might come from packet inspections, it slows down the traffic to the point where the tap adaptor times out and shuts down. Some firewall rules might also do this, it gets hit by so many UDP packets that it gets congested causing the timeout. This would explain why TCP helps because the packets would be resent keeping the TAP adapter working. To check this theory it would be necessary to talk to someone at Microsoft that worked on coding the TAP adapter, not difficult to do.
This is different to the explanation I got from support, that the TAP adapter was still in use so disabling and reenabling it freed it up. Some earlier versions of the TAP adapter might have a different timeout or not shut down, that would explain why they help sometimes. But the problem seems to be in this congestion in the torrent program, the openvpn driver, or the router.
The solution then is simple, make sure the TAP adapter doesn't shut down. There is a setting that is called media status in the advanced tab. This is set to application controlled, that probably means an application is closing the TAP adapter when the packets get too congested. We don't know what that application is, it might be a Microsoft driver not the openvpn driver. Just set this to always connected. Now the TAP adapter cannot shut down from congestion. Since doing this it has never once dropped out for me with torrenting. I don't see how it can drop out with this setting.
It may not work for you, however I have not been able to find this solution posted anywhere on vpn forums. It makes sense and seems to explain why the fixes work a bit, and it is not dropping out for me any more. My explanation is probably not completely accurate, it would be necessary to talk to someone coding these drivers to get the exact situation.
Thanks for the tip! I think your story holds. Let me start off by saying that disabling and enabling the TAP driver ends the loop (disconnecting > authorization failed and so fort) in which Eddie gets stuck after my torrents nosedive to 0kb/s. That said, I have tried every solution available on the forum and none would work:
- Reinstalling Eddie
- Reinstalling my network drivers
- Using a different version of Eddie (2.10 and 2.11)
- Using a different version of the TAP driver (9.21.0, 9.21.1 and 9.21.2) -> haven't been able to install any version of the 9.9 driver on the latest build of Windows 10 (build 14393), it persistently gives me an error (which makes sense, because the driver was meant for Windows XP and older)
- Changing the media status to always connected
I have finally managed to fix the problem by changing the packet rules of my Kasperksy firewall. The local services (TCP and UDP) - inbound were set to "block". By changing them to "by application rules" and adding AirVPN and the TAP driver to the trusted applications, my problem with p2p software was fixed.