ComputerSteve
Senior Member
I notice that the script only works when I run it manually ? Is this supposed to monitor the connection automatically at reboot? Meaning do I always have to do Launch VPNMON-R2 into Normal Monitoring Mode?
VPNMON VPNMON-R2 v2.52 -Mar 27, 2023- Monitor your VPN connection's Health (Thread locked/closed)
- Thread starter Viktor Jaep
- Start date
Viktor Jaep
Part of the Furniture
Hey @ComputerSteve ...That's by design... I don't have any options to auto-start the script on router reboot, but I do have some guidance listed under this section if you want to implement it like I did?
VPNMON - VPNMON-R2 v2.52 -Mar 27, 2023- Monitor your VPN connection's Health (Thread locked/closed)
v2.52 - Now with even more SuperRandom(tm) goodness!! Updated March 27, 2023 Executive Summary: VPNMON-R2 is an all-in-one script that works for any VPN service of your choice, but is optimized for NordVPN, SurfShark VPN, WeVPN and Perfect Privacy VPN services. It can also compliment @JackYaz's...
www.snbforums.com
In order for it to run without any intervention from you directly from the router itself, you would want to use the -screen option. To connect to it, you would just enter "vpnmon-r2 -screen", and to disconnect, "CTRL - A + D"
Viktor Jaep
Part of the Furniture
Moving this discussion over to this thread, since we're probably way off-topic in the main Merlin threads.
So there's not much I can do within the AMTM screen to show status/enabled/disabled... but I can very likely have the -pause command work on autostart. I could even provide some kind of status feedback command, like "vpnmon-r2 -status", and it kicks back some sort of status indicator... but it would be all inside an SSH window outside of amtm. So how do you foresee this working?
1. You reboot your router
2. vpnmon-r2 is executed with a -pause command with auto start, and sits in the background
3. what will cause it to resume? will you run a vpnmon-r2 -resume command, and at what point? or will you automate this? or will you hit a key on the pause screen inside vpnmon-r2?
4. where do you foresee needing to see the status?
ComputerSteve
Senior Member
So basically it would just be if I have to edit a vpn config id pause it. Right now with the auto start on boot script the only way I can tell your script is working is after I reboot I notice it automatically starts a vpn client. I’m assuming it’s starting the best one based on ping since that’s what I have it set to. I just notice that with the script automatically started I can’t edit a client it isn’t picking without removing that auto start code then rebooting. If I try to edit it stops all the clients then again picks the one with the right ping. That doesn’t allow me to see if the server I just edited is working.Moving this discussion over to this thread, since we're probably way off-topic in the main Merlin threads.
So how do you foresee this working?
1. You reboot your router
2. vpnmon-r2 is executed with a -pause command with auto start, and sits in the background
3. what will cause it to resume? will you run a vpnmon-r2 -resume command, and at what point? or will you automate this? or will you hit a key on the pause screen inside vpnmon-r2?
4. where do you foresee needing to see the status?
Viktor Jaep
Part of the Furniture
The other was you can tell if the script is running is by making a connection to it...
Code:
vpnmon-r2 -screen
or,
screen -r vpnmon-r2I'll start working on some pause/resume/status commands in the interim...
Hello,
First of all, thanks for developping this tool which i found very interesting and helpfull. I started using in last 3 days VPNMON-R2 V2.26 and I wanted to share my findings.
Based on the logs below seems there are dropped connection, it started closely at 1:00AM and finish 7:40AM. Every minute there is a WAN issue detected.
….
But as you can see by picture (avg ping for google dns, check every 60s) there are no dropped connection (and I also have not encountered any dropped connections personally).
From 1:00AM till 7:40AM it was running upload job to cloud which is intensive and utilize close to 100% bandwidth. The local server which uploads the data is not using VPN tunel (the IP is excluded from VPN tunel, set via VPN director).
Why the log shows dropped connections ? I do think connection was active and running well.
Thanks
First of all, thanks for developping this tool which i found very interesting and helpfull. I started using in last 3 days VPNMON-R2 V2.26 and I wanted to share my findings.
Based on the logs below seems there are dropped connection, it started closely at 1:00AM and finish 7:40AM. Every minute there is a WAN issue detected.
….
Code:
Mon Oct 17 07:29:14 CEST 2022 - VPNMON-R2 - WAN Link Detected -- Trying to reconnect/Reset VPN
Mon Oct 17 07:30:18 CEST 2022 - VPNMON-R2 - Executing VPN Reset
Mon Oct 17 07:30:28 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Mon Oct 17 07:30:29 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED
Mon Oct 17 07:30:29 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED. VPN RESET TERMINATED.
Mon Oct 17 07:30:35 CEST 2022 - VPNMON-R2 - WAN Link Detected -- Trying to reconnect/Reset VPN
Mon Oct 17 07:31:39 CEST 2022 - VPNMON-R2 - Executing VPN Reset
Mon Oct 17 07:31:48 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Mon Oct 17 07:31:49 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED
Mon Oct 17 07:31:49 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED. VPN RESET TERMINATED.
Mon Oct 17 07:31:55 CEST 2022 - VPNMON-R2 - WAN Link Detected -- Trying to reconnect/Reset VPN
Mon Oct 17 07:33:00 CEST 2022 - VPNMON-R2 - Executing VPN Reset
Mon Oct 17 07:33:09 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Mon Oct 17 07:33:10 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED
Mon Oct 17 07:33:10 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED. VPN RESET TERMINATED.
Mon Oct 17 07:33:16 CEST 2022 - VPNMON-R2 - WAN Link Detected -- Trying to reconnect/Reset VPN
Mon Oct 17 07:34:20 CEST 2022 - VPNMON-R2 - Executing VPN Reset
Mon Oct 17 07:34:30 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Mon Oct 17 07:34:31 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED
Mon Oct 17 07:34:31 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED. VPN RESET TERMINATED.
Mon Oct 17 07:34:37 CEST 2022 - VPNMON-R2 - WAN Link Detected -- Trying to reconnect/Reset VPN
Mon Oct 17 07:35:41 CEST 2022 - VPNMON-R2 - Executing VPN Reset
Mon Oct 17 07:35:50 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Mon Oct 17 07:35:51 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED
Mon Oct 17 07:35:51 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED. VPN RESET TERMINATED.
Mon Oct 17 07:35:57 CEST 2022 - VPNMON-R2 - WAN Link Detected -- Trying to reconnect/Reset VPN
Mon Oct 17 07:37:02 CEST 2022 - VPNMON-R2 - Executing VPN Reset
Mon Oct 17 07:37:11 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Mon Oct 17 07:37:12 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED
Mon Oct 17 07:37:12 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED. VPN RESET TERMINATED.
Mon Oct 17 07:37:18 CEST 2022 - VPNMON-R2 - WAN Link Detected -- Trying to reconnect/Reset VPN
Mon Oct 17 07:38:22 CEST 2022 - VPNMON-R2 - Executing VPN Reset
Mon Oct 17 07:38:31 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Mon Oct 17 07:38:32 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED
Mon Oct 17 07:38:32 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED. VPN RESET TERMINATED.
Mon Oct 17 07:38:38 CEST 2022 - VPNMON-R2 - WAN Link Detected -- Trying to reconnect/Reset VPN
Mon Oct 17 07:39:43 CEST 2022 - VPNMON-R2 - Executing VPN Reset
Mon Oct 17 07:39:52 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Mon Oct 17 07:39:53 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED
Mon Oct 17 07:39:53 CEST 2022 - VPNMON-R2 ----------> ERROR: WAN CONNECTIVITY ISSUE DETECTED. VPN RESET TERMINATED.
Mon Oct 17 07:39:59 CEST 2022 - VPNMON-R2 - WAN Link Detected -- Trying to reconnect/Reset VPN
Mon Oct 17 07:41:03 CEST 2022 - VPNMON-R2 - Executing VPN Reset
Mon Oct 17 07:41:13 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Mon Oct 17 07:41:31 CEST 2022 - VPNMON-R2 - Refreshed VPN Slots 1 - 5 from 5 Recommended NordVPN Server Locations
Mon Oct 17 07:41:33 CEST 2022 - VPNMON-R2 - Randomly selected VPN2 Client ON
Mon Oct 17 07:41:37 CEST 2022 - VPNMON-R2 - VPN Reset Finished
Mon Oct 17 07:41:39 CEST 2022 - VPNMON-R2 - Trimmed the log file down to 1000 lines
Mon Oct 17 07:41:53 CEST 2022 - VPNMON-R2 - API call made to update WAN0 city to Boskovice
Mon Oct 17 07:41:53 CEST 2022 - VPNMON-R2 - API call made to update VPN city to PragueBut as you can see by picture (avg ping for google dns, check every 60s) there are no dropped connection (and I also have not encountered any dropped connections personally).
From 1:00AM till 7:40AM it was running upload job to cloud which is intensive and utilize close to 100% bandwidth. The local server which uploads the data is not using VPN tunel (the IP is excluded from VPN tunel, set via VPN director).
Why the log shows dropped connections ? I do think connection was active and running well.
Thanks
Viktor Jaep
Part of the Furniture
That's a pretty interesting observation, @salvo! When it does a WAN connectivity check, it does a pretty intense couple of bundled commands using netcat and openssl to connect to and establish an SSL connection... I have a feeling your 100% bandwidth utilization was probably enough to make it timeout, and think that the WAN was down, since it couldn't make that connection. It will then loop and wait 60 seconds before trying again. I'll see if I can play with timeout values at all to give it a better chance at verifying the WAN connection during heavy loads like this. Thanks!
EDIT: Yeah, timeout was set for 1 second... I've bumped it to 3 seconds, so let's see what happens! Feel free to check back and give me an update after you've tried the new release coming soon, OK?
Last edited:
Viktor Jaep
Part of the Furniture
It's got a debug mode, but it's messy, and typically use it to solve hard-to-solve programming issues... but don't have anything that would increase/decrease log verbosity. If you have any good ideas on what you would like to see, I could look into making this a possibility?
Viktor Jaep
Part of the Furniture
OK... it's Oct 18, 2022 somewhere in this world right now... (right, @Stephen Harrington? ) Extremely pleased to announce VPNMON-R2 v2.32! Thanks very much to @ComputerSteve for his extensive beta testing these past couple of days, and for his great suggestions... This release comes packed with lots of new goodies to make it even better!
What's new?
v2.30 - (October 18, 2022)
- MAJOR: Another method of picking VPN slots has been introduced to the mix, namely, the "Round Robin" method. Instead of randomly picking slots, VPNMON-R2 will pick the next VPN slot in line. Ex: If you are using VPN Slot #1 and it fails, it will connect to VPN Slot #2, then 3, etc. VPNMON-R2 will keep track of the slot last used, and will survive a reboot, so that it will correctly pick that next slot in line. Under setup->config, please choose option 5 - how you want your VPN slots chosen, select "Round Robin". Thanks @ComputerSteve for asking to include this!
- ADDED: Now includes logic to PAUSE, RESUME and inquire about a current STATUS of VPNMON-R2. With thanks to @ComputerSteve for the suggestion. When running the command "vpnmon-r2 -pause", the currently running instance of VPNMON-R2 will enter a "paused" state. While in this paused state, it will not check for any VPN anomalies until it is resumed once again. Entering the command "vpnmon-r2 -resume" will allow the currently running instance to resume normal operations. Last, using the "vpnmon-r2 -status" command gives an indication what state VPNMON-R2 is currently operating in, along with the last known VPN slot being used.
- ADDED: Another stats row, containing information regarding the VPN Slot Selection Method, the number of chances it gets (in case it's set for the Lowest PING method), the number of PING retries before reset, and the minimum PING allowable across the VPN tunnel before a reset.
- ADDED: A check when executing 'vpnmon-r2 -monitor' to display a warning message if an existing session running vpnmon-r2 is already running under the Screen utility. Please know, that running the -monitor command will not prevent you from running 2 instances of vpnmon-r2 at the same time, but it will warn you that conflict can very likely occur.
- CHANGED: When bringing up the setup/config menu from within the UI, the UI will now refresh and use the changes that were made to the config. This prevents you from having to stop and restart the script to accept changes. Been needing to do this for a while, so thanks again to @ComputerSteve for lighting a fire under my butt.
- CHANGED: Increased the timeout value for netcat when doing a WAN check from 1s to 3s. This should help alleviate instances of false WAN-down detection during times of high bandwidth utilization. Thanks to @salvo for reporting this!
- FIXED: Added a few more references for the VPN status file to be written to during other types of vpnreset events so the status file reflects accurately throughout.
- FIXED: Minor code improvements and optimizations. Eliminated some inefficient code from v0.1 that has been nagging my OCD for quite a while.
v2.31 - (October 18, 2022)
- HOTFIX: The logic to determine whether or not a secondary vpnmon-r2 session was already running after executing a concurrent -monitor command wasn't working out correctly. This was fixed (awaiting confirmation). Thanks much to @Stephen Harrington for his keen eye on this!
v2.32 - (October 18, 2022)
- HOTFIX2: I have backed out this code to determine concurrent sessions for further testing in the next round of betas. v2.32 is the new stable version.
Download link (or update directly from within AMTM itself):
Significant Screenshots:
The new VPN slot method "Round Robin" is available under option #5 of the -config menu!
The new stats row, showing method, # of chances (for Lowest Ping method), # of pings before a reset, and # of ms before a reset
) Extremely pleased to announce VPNMON-R2 v2.32! Thanks very much to @ComputerSteve for his extensive beta testing these past couple of days, and for his great suggestions... This release comes packed with lots of new goodies to make it even better!What's new?
v2.30 - (October 18, 2022)
- MAJOR: Another method of picking VPN slots has been introduced to the mix, namely, the "Round Robin" method. Instead of randomly picking slots, VPNMON-R2 will pick the next VPN slot in line. Ex: If you are using VPN Slot #1 and it fails, it will connect to VPN Slot #2, then 3, etc. VPNMON-R2 will keep track of the slot last used, and will survive a reboot, so that it will correctly pick that next slot in line. Under setup->config, please choose option 5 - how you want your VPN slots chosen, select "Round Robin". Thanks @ComputerSteve for asking to include this!
- ADDED: Now includes logic to PAUSE, RESUME and inquire about a current STATUS of VPNMON-R2. With thanks to @ComputerSteve for the suggestion. When running the command "vpnmon-r2 -pause", the currently running instance of VPNMON-R2 will enter a "paused" state. While in this paused state, it will not check for any VPN anomalies until it is resumed once again. Entering the command "vpnmon-r2 -resume" will allow the currently running instance to resume normal operations. Last, using the "vpnmon-r2 -status" command gives an indication what state VPNMON-R2 is currently operating in, along with the last known VPN slot being used.
- ADDED: Another stats row, containing information regarding the VPN Slot Selection Method, the number of chances it gets (in case it's set for the Lowest PING method), the number of PING retries before reset, and the minimum PING allowable across the VPN tunnel before a reset.
- ADDED: A check when executing 'vpnmon-r2 -monitor' to display a warning message if an existing session running vpnmon-r2 is already running under the Screen utility. Please know, that running the -monitor command will not prevent you from running 2 instances of vpnmon-r2 at the same time, but it will warn you that conflict can very likely occur.
- CHANGED: When bringing up the setup/config menu from within the UI, the UI will now refresh and use the changes that were made to the config. This prevents you from having to stop and restart the script to accept changes. Been needing to do this for a while, so thanks again to @ComputerSteve for lighting a fire under my butt.
- CHANGED: Increased the timeout value for netcat when doing a WAN check from 1s to 3s. This should help alleviate instances of false WAN-down detection during times of high bandwidth utilization. Thanks to @salvo for reporting this!
- FIXED: Added a few more references for the VPN status file to be written to during other types of vpnreset events so the status file reflects accurately throughout.
- FIXED: Minor code improvements and optimizations. Eliminated some inefficient code from v0.1 that has been nagging my OCD for quite a while.
v2.31 - (October 18, 2022)
- HOTFIX: The logic to determine whether or not a secondary vpnmon-r2 session was already running after executing a concurrent -monitor command wasn't working out correctly.
v2.32 - (October 18, 2022)
- HOTFIX2: I have backed out this code to determine concurrent sessions for further testing in the next round of betas. v2.32 is the new stable version.
Download link (or update directly from within AMTM itself):
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-2.32.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod a+rx "/jffs/scripts/vpnmon-r2.sh"Significant Screenshots:
The new VPN slot method "Round Robin" is available under option #5 of the -config menu!
The new stats row, showing method, # of chances (for Lowest Ping method), # of pings before a reset, and # of ms before a reset
Last edited:
Some input from me to consider future developments
1.) Add detected ping value, which VPN tunel has been reseted and what was WAN link ping to logging file
2.) Add detected ping value to WAN link to logging file
3.) Scheduling the start & stop screening i.e. auto cron list management
More question than feature:
Not sure so asking does the logic consider WAN ping vs. VPN ping. I am asking myself, why to reset the connection when WAN ping and VPN pings are similar ?
1.) Add detected ping value, which VPN tunel has been reseted and what was WAN link ping to logging file
Code:
Tue Oct 18 10:19:45 CEST 2022 - VPNMON-R2 ----------> WARNING: AVG PING across VPN tunnel > 100 ms - Executing VPN Reset2.) Add detected ping value to WAN link to logging file
Code:
Mon Oct 17 07:26:33 CEST 2022 - VPNMON-R2 - WAN Link Detected -- Trying to reconnect/Reset VPN3.) Scheduling the start & stop screening i.e. auto cron list management
More question than feature:
Not sure so asking does the logic consider WAN ping vs. VPN ping. I am asking myself, why to reset the connection when WAN ping and VPN pings are similar ?
Last edited:
Viktor Jaep
Part of the Furniture
Great suggestions, @salvo... I'll consider adding your requests in an upcoming revision.
There is a combo of WAN vs VPN pinging going on in the background, but a ping across the tunnel is especially important to determine if the tunnel connection is still viable, meaning the VPN provider is having issues, but your WAN connection is not experiencing any issues.
My opinion on WAN ping vs VPN ping is as follows: when WAN ping is close to 120ms and VPN ping is 130ms (for whatever reason, ie heavy upload/download
)... why reset VPN, not sure what is expected here to happen ?After testing v2.31 for several hours, see my observation about switching to faster VPN.
Does the switching to faster VPN2 client happen after reaching > 100ms ? From the log, it is not visible i.e. I do not have visibility what was the condition(s) to switch.
Does the switching to faster VPN2 client happen after reaching > 100ms ? From the log, it is not visible i.e. I do not have visibility what was the condition(s) to switch.
Code:
Tue Oct 18 13:33:58 CEST 2022 - VPNMON-R2 - API call made to update VPN city to Prague
Tue Oct 18 13:59:55 CEST 2022 - VPNMON-R2 ----------> WARNING: Switching to faster VPN2 Client - Executing VPN Reset
Tue Oct 18 13:59:55 CEST 2022 - VPNMON-R2 - Executing VPN Reset to Slot with Lowest PING
Tue Oct 18 14:00:06 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Tue Oct 18 14:00:17 CEST 2022 - VPNMON-R2 - VPN2 Client ON - Lowest PING of 5 VPN slots
Code:
_ ______ _ ____ _______ _ __ ____ ___
| | / / __ \/ | / / |/ / __ \/ | / / / __ \__ \ v2.31
| | / / /_/ / |/ / /|_/ / / / / |/ /_____/ /_/ /_/ /
| |/ / ____/ /| / / / / /_/ / /| /_____/ _, _/ __/
|___/_/ /_/ |_/_/ /_/\____/_/ |_/ /_/ |_/____/
----------------------------------------------------------------
Configuration Utility Options
----------------------------------------------------------------
1 : Ping Retries Before Reset? :3
2 : Timer Interval to Check VPN? :60
3 : Host IP to PING against? :8.8.8.8
4 : Update VPNMGR? :No
5 : How VPN Slots are Chosen? :Lowest PING
|-- Chances before Reset? :5
6 : Current VPN Provider? :NordVPN
|-- Enable SuperRandom? :No
|-- VPN Country (Multi?) :Czech Republic
|-- % Server Load Threshold? :50
|-- Update Skynet? :No
|-- Use Recommended Server(s)? :Yes
7 : Perform Daily VPN Reset? :Yes
|-- Daily Reset Time? :02:00
8 : Minimum PING Before Reset? :100
9 : VPN Client Slots Configured? :5
10 : Show Near-Realtime Stats? :Yes
11 : Delay Script Startup? :0
12 : Trim Logs Daily? :Yes
|-- Max Log File Size? :1000
13 : Sync Current VPN with Yazfi? :No
|-- YazFi Slots 1-9 Synced :Disabled
|
s : Save & Exit
e : Exit & Discard Changes
----------------------------------------------------------------
Selection:Viktor Jaep
Part of the Furniture
Nope, the "Minimum Ping" of 100ms is a completely different qualifier to reset your VPN connection, aside from the "Lowest Ping" method on how VPN Client slots are chosen. Here's a brief explanation:
1.) Minimum Ping -- the minimum # of milliseconds that you have specified that will cause VPNMON-R2 to drop your VPN connection in favor of finding another VPN connection that is below this number. Please note, if you are connecting long distances (from continent to continent, or across your country), you may want to increase this based on your observations.
2.) Lowest Ping Method -- This is the method at how your VPN Client Slots are selected -- the other choices are (a) Random and (b) Round Robin. The Lowest Ping method takes a look at all 5 slots (or however many slots you have identified) and pings each over the WAN. The lowest ping will typically mean the fastest, and will go through 5 chances (or however many you have specified) to determine if it will truly be the lowest ping server. After 5 chances, and nothing else has beat it, it will drop connection, and connect to the fastest ping VPN slot. And you are correct - the log doesn't give much info on who or why, but you would get a good idea from looking at the UI.
Thanks, understand, so why did it trigger the switch to faster VPN at first place ? What triggered the reset ? You can see below it switches but not sure why.
Code:
Tue Oct 18 18:44:43 CEST 2022 - VPNMON-R2 - A new update (v2.32) is available to download
Tue Oct 18 18:52:13 CEST 2022 - VPNMON-R2 ----------> WARNING: Switching to faster VPN3 Client - Executing VPN Reset
Tue Oct 18 18:52:13 CEST 2022 - VPNMON-R2 - Executing VPN Reset to Slot with Lowest PING
Tue Oct 18 18:52:23 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Tue Oct 18 18:52:34 CEST 2022 - VPNMON-R2 - VPN3 Client ON - Lowest PING of 5 VPN slots
Tue Oct 18 18:52:38 CEST 2022 - VPNMON-R2 - VPN Reset Finished
Tue Oct 18 18:52:41 CEST 2022 - VPNMON-R2 - A new update (v2.32) is available to download
Tue Oct 18 18:52:41 CEST 2022 - VPNMON-R2 - Trimmed the log file down to 1000 lines
Tue Oct 18 18:52:41 CEST 2022 - VPNMON-R2 - Resuming normal operations
Tue Oct 18 18:52:53 CEST 2022 - VPNMON-R2 - API call made to update WAN0 city to Boskovice
Tue Oct 18 18:52:53 CEST 2022 - VPNMON-R2 - API call made to update VPN city to Prague
Tue Oct 18 19:00:47 CEST 2022 - VPNMON-R2 ----------> WARNING: Switching to faster VPN1 Client - Executing VPN Reset
Tue Oct 18 19:00:47 CEST 2022 - VPNMON-R2 - Executing VPN Reset to Slot with Lowest PING
Tue Oct 18 19:00:58 CEST 2022 - VPNMON-R2 - Killed all VPN Client Connections
Tue Oct 18 19:01:09 CEST 2022 - VPNMON-R2 - VPN1 Client ON - Lowest PING of 5 VPN slots
Tue Oct 18 19:01:13 CEST 2022 - VPNMON-R2 - VPN Reset Finished
Last edited:
Viktor Jaep
Part of the Furniture
You've chosen to use recommended servers, so they're all close and have similar ping values. VPN 3 might be 18.034ms, VPN 1 might be 17.234ms, so it's going to choose VPN 1 after 5 chances (60sec intervals) if it still is considered the fastest server. Watching the UI gives you a lot of insight on what's happening and encourage you to take a look at that instead of the logs.
Viktor Jaep
Part of the Furniture
Yes... the Lowest PING method looks at all 5 of your VPN slots:
Interval 1 (60 sec)
VPN1 - 18.301ms (ACTIVE)
VPN2 - 20.195ms
VPN3 - 22.441ms
VPN4 - 17.113ms <--- this one is the lowest, and will switch to this after 5 chances (intervals)
VPN5 - 21.943ms
....
Interval 5 (60 sec)
VPN1 - 19.301ms (ACTIVE)
VPN2 - 21.195ms
VPN3 - 24.441ms
VPN4 - 18.113ms <--- this one is the still the lowest, and will switch to this after the interval #5 completes
VPN5 - 24.943ms
The Minimum PING before reset looks at the current ACTIVE VPN slot:
VPN1 - 48.301ms (ACTIVE) <--- It is still below 100ms, so it will stay connected...
VPN2 - 90.195ms
VPN3 - 122.441ms
VPN4 - 127.113ms
VPN5 - 211.943ms
... however, if VPN1 starts getting overloaded
The Minimum PING before reset looks at the current ACTIVE VPN slot:
VPN1 - 148.301ms (ACTIVE) <--- It is ABOVE 100ms, so it will disconnect, and try to find another connection < 100ms...
VPN2 - 90.195ms
VPN3 - 122.441ms
VPN4 - 127.113ms
VPN5 - 211.943ms
Similar threads
Similar threads
Similar threads
-
(Not specifically) VPNMON-R3 1.11 failure domino effect- Started by Ripshod
- Replies: 20
-
VPNMON VPNMON-R3 Custom Server List Generation Tutorials and Examples
- Started by Viktor Jaep
- Replies: 63
Latest threads
-
-
Ubuntu Linux impacted by decade-old 'needrestart' flaw that gives root- Started by PR3MIUM
- Replies: 0
-
-
-
Support SNBForums w/ Amazon
If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!