SparkLabs Forum.

Community Help.


Viscosity hangs when connection drops

Hi Eric

With the h/w, there was no offence taken &, as said, I knew in writing that I may have been being pernickety. That said, as Viscosity's typically using ~0.5-2% of the CPU, when working properly of course, then it doesn't inherently appear to be underpowered for the usage - though clearly I'm not attempting to do huge amounts of multitasking along with.


As to what to test, it was primarily that you'd thrown 2 options at me, & it wasn't clear at all if the beta was an attempt to permanently correct the issue & so should be run without the mute 20 or not... ...& as you sensibly need feedback so that you know if there's still any issues then this was the point in questioning.

Not to worry though.


Then, as to where things are now, what's happened twice over the weekend is coming in to find the machine unable to connect at the yellow triangle network connection error (I can't think what it's now called in Win10)... This has happened with both the last stable version & the new beta (both with mute 20) // it requires Viscosity to be killed to resolve & other devices can still connect to the internet // but doesn't cause either high CPU or memory usage.


& lastly, as probably something of an aside, am I correct in thinking that the issue mentioned on iPredator's Twitter feed mentioned on the 20th (https://twitter.com/IPredatorVPN), which I noticed yesterday, relates to the reachability error message?

Now, to be clear, that message has only ever come up spasmodically on initial connecting over the last 3.5 weeks (lasting for anything from a couple of minutes to maybe an hour) // has never been the latest thing in the log at the time when there's been a problem with Viscosity locking up &/or killing the connection // & i started intermittently getting that error around the 5th (predating 1.6)... ...so I naturally assumed that it was an issue at their end since the version of Viscosity being used hadn't changed at that point.
Hi PocketDemon,

Does this mean Viscosity is still locking up when you need to kill the process? When you kill Viscosity, is there an openvpn.exe process running as well? If there is, does killing openvpn.exe cause Viscosity to become responsive again if it is still becoming unresponsive?

The issue isn't with CPU load, it's the operating system and other hardwares ability to process very small operations very quickly one after the other. CPU usage from Task Manager or Process Monitor is not a good indicator in this scenario.

Regards,
Eric
Hi PocketDemon,

Another question, do you have verb defined in your configuration? You can check this by editing the connection and going to Advanced. If so, what level?

Regards,
Eric
Sorry, that was poor phrasing on my part - what I meant to say was that I needed to unload & then, having waited a few seconds for the connection to sort itself, reload Viscosity in order to get around the yellow triangle issue; not that Viscosity had frozen & *had* to be shut down using the Task Manager.

if/when it happens again, I'll try forcing the OpenVPN to shut down & report back.


& the configuration settings are literally the iPredator defaults + the mute 20 -

resolv-retry infinite
tls-client
remote-cert-tls server
remote-cert-ku 0x00e0
keepalive 10 30
cipher AES-256-CBC
mssfix 1200
route-delay 5
replay-window 512 60
mute-replay-warnings
ifconfig-nowarn
dev-node {4D6A272F-9A21-4D9F-9876-4F7A92848D7C}
mute 20
Hi PocketDemon,

It's definitely worth taking a look at the log when this occurs to see if there are any errors or warnings present, they could point to what the problem is:
http://sparklabs.com/support/kb/article ... envpn-log/

Regards,
Eric
25 posts Page 3 of 3

Copyright © 2016 SparkLabs Pty Ltd. All Rights Reserved. Privacy Policy