Viktor Jaep
Part of the Furniture
Very well may have... LOLI seem to recall it was the same in R2, checking during cycle, wasn't it?
Very well may have... LOLI seem to recall it was the same in R2, checking during cycle, wasn't it?
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R3/main/vpnmon-r3-1.04b4.sh" -o "/jffs/scripts/vpnmon-r3.sh" && chmod 755 "/jffs/scripts/vpnmon-r3.sh"
Update Utility
This utility allows you to check, download and install updates
---------------------------------------------------------------------------------------
Current Version: 1.04b4
Updated Version: 1.03
Score! There is a new version out there! Would you like to update?
[y/n]?
2.) Reset switch immediately switch to waiting screen, so far so good...in average in my cases takes around 2min 47sec to restart 3 VPN connections (with 5 recommended server list per VPN connection)- FIXED: When the -reset switch is thrown, VPNMON-R3 will immediately drop to the waiting screen. Thanks to @salvo for noticing!
(6) : Provide additional WAN/Dual WAN monitoring : Disabled
I could just disable the update menu while on a beta version, or, it would allow someone to downgrade back to stable. I'll just leave it be.1.) Just a small bug, script considers 1.03 higher than 1.04 beta
I bumped up the amount of time between segments (stopping, starting, settling, etc.) so that processes don't walk over each other. I would love to shorten the time, but I've got more testing to do. I have some other ideas to determine if I can move quicker between steps. The main concern is making sure it's stable and reliable... not flaky and random.2.) Reset switch immediately switch to waiting screen, so far so good...in average in my cases takes around 2min 47sec to restart 3 VPN connections (with 5 recommended server list per VPN connection)
Good catch... I have it checking WAN in 2 different places... must have forgotten about checking for exceptions at one of them3.) Not sure if this is meant to be this way but WAN checking is disabled however script checks the WAN connectivity
Code:(6) : Provide additional WAN/Dual WAN monitoring : Disabled
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R3/main/vpnmon-r3-1.04b5.sh" -o "/jffs/scripts/vpnmon-r3.sh" && chmod 755 "/jffs/scripts/vpnmon-r3.sh"
Fully agree, it was just a comment about the average time it takes, not an emphasis on improvement.The main concern is making sure it's stable and reliable... not flaky and random.
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R3/main/vpnmon-r3-1.04b6.sh" -o "/jffs/scripts/vpnmon-r3.sh" && chmod 755 "/jffs/scripts/vpnmon-r3.sh"
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R3/main/vpnmon-r3-1.10.sh" -o "/jffs/scripts/vpnmon-r3.sh" && chmod 755 "/jffs/scripts/vpnmon-r3.sh"
Wow! You been busyThank you for all your feedback to those who have been testing the new VPNMON-R3 version these last few weeks! The newest version is out -- below is a huge slew of fixes and changes to be found in v1.10 (with rolled up changelogs from the previous betas)! With this version, I am also sadly announcing the sunset of VPNMON-R2. Changes have been made to R3 to provide an uninstallation process of R2 if it's still present on your router.
What's new!?
VPNMON-R3 v1.10 - (January 23, 2024)
- MAJOR: VPNMON-R2 sunset notification banner is added if found that R2 is still installed. I have made the difficult decision to sunset VPNMON-R2, and drive adoption of R3 so that I may focus on developing it further. When pressing the (X) key, users will be driven to an R2 uninstall menu, allowing you to uninstall all R2 files and components directly from R3. Similarly, in R2, an update banner will be prominently displayed at all times, driving people to the update menu, to upgrade to R3 directly from within R2. In the near future, new installs of R2 will no longer be possible, and will be driven to install R3.
- MAJOR: In one of the recent storms that brough down my WAN connection, I quickly found out that VPNMON-R3 does not like that, and caused the script to hang for some unknown reason. Thinking it might be a good idea to break out the WAN monitoring functionality from R2, this has now been incorporated as a selectable option. When enabled, VPNMON-R3 will test the WAN on each cycle, and if determined that the WAN is down, will kill your VPN connections, and fall back into a graceful loop where it periodically tests the WAN connection in order to start the VPN connection(s) back up. As with R2, this will look at both WAN0 and WAN1, and should be able to correctly display the necessary information for those running those fancy Dual-WAN configurations. This has been tested on a single WAN0 connection where I completely powered off the modem, simulating a WAN outage, and bringing back up to ensure R3 was able to recover correctly.
- ADDED: Under the Run Automations operations menu item, the ability to import your custom VPN Slot lists into Skynet is now a possibility! In the past, certain blocklists would also prevent you from connecting to certain VPN servers because they were actively being blocked. From this menu, pressing s1-s5 will import the contents directly to Skynet, giving you peace of mind that your VPN server endpoints are whitelisted.
- ADDED: More checks while determining vpn health, and adding more logic around failed connections, including an indicator showing the number of attempts a certain vpn slot has undergone if it comes back failing the ping and curl tests.
- ADDED: Also, timing delays to allow for tunnels to connect, disconnect and settle have been extended. No, your router hasn't slowed down. I'm just making sure processes aren't stepping over each other to give you the most stable monitoring experience.
- ADDED: When a VPN connection fails, an intermediate 5 second counter will appear allowing you to (P)ause execution. This allows you to enter the Operations Menu, should you need to make any adjustments. I found that with successive failures, it was nearly impossible to get to the Operations menu in order to exclude a certain slot that was causing issues.
- ADDED: Few more log entries for various reset conditions were added.
- FIXED: The timing on connecting, stopping and settling have been dropped slightly. Also, shaved more time by not spending 10 seconds forcing a service_stop on a connection that has already stopped. Likewise, checking for VPN slots in an error (-1) state, and force stopping these, then forcing an NVRAM state reset on them to change them back to 0 (disconnected).
- FIXED: WAN checks were still happening even when disabled. Thanks to @salvo! Fixed!
- FIXED: When the -reset switch is thrown, VPNMON-R3 will immediately drop to the waiting screen. Thanks to @salvo for noticing!
- FIXED: Minor corrections to wording or other on-screen layouts to make the UI more pleasing to the eye.
- FIXED: Made some revisions to how variables were used in order to cut down on some Unknown Operand errors that were initially captured by @Ripshod. Thank you!
Download link:
Code:curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R3/main/vpnmon-r3-1.10.sh" -o "/jffs/scripts/vpnmon-r3.sh" && chmod 755 "/jffs/scripts/vpnmon-r3.sh"
Significant Screenshots:
View attachment 55902
Have gone through all the betas and currently running b6. It has kept my three tunnels up and I have eliminated the daily restart. Can see that it is working as now I show variable up times on each tunnel.Thank you for all your feedback to those who have been testing the new VPNMON-R3 version these last few weeks! The newest version is out -- below is a huge slew of fixes and changes to be found in v1.10 (with rolled up changelogs from the previous betas)! With this version, I am also sadly announcing the sunset of VPNMON-R2. Changes have been made to R3 to provide an uninstallation process of R2 if it's still present on your router.
What's new!?
VPNMON-R3 v1.10 - (January 23, 2024)
- MAJOR: VPNMON-R2 sunset notification banner is added if found that R2 is still installed. I have made the difficult decision to sunset VPNMON-R2, and drive adoption of R3 so that I may focus on developing it further. When pressing the (X) key, users will be driven to an R2 uninstall menu, allowing you to uninstall all R2 files and components directly from R3. Similarly, in R2, an update banner will be prominently displayed at all times, driving people to the update menu, to upgrade to R3 directly from within R2. In the near future, new installs of R2 will no longer be possible, and will be driven to install R3.
- MAJOR: In one of the recent storms that brough down my WAN connection, I quickly found out that VPNMON-R3 does not like that, and caused the script to hang for some unknown reason. Thinking it might be a good idea to break out the WAN monitoring functionality from R2, this has now been incorporated as a selectable option. When enabled, VPNMON-R3 will test the WAN on each cycle, and if determined that the WAN is down, will kill your VPN connections, and fall back into a graceful loop where it periodically tests the WAN connection in order to start the VPN connection(s) back up. As with R2, this will look at both WAN0 and WAN1, and should be able to correctly display the necessary information for those running those fancy Dual-WAN configurations. This has been tested on a single WAN0 connection where I completely powered off the modem, simulating a WAN outage, and bringing back up to ensure R3 was able to recover correctly.
- ADDED: Under the Run Automations operations menu item, the ability to import your custom VPN Slot lists into Skynet is now a possibility! In the past, certain blocklists would also prevent you from connecting to certain VPN servers because they were actively being blocked. From this menu, pressing s1-s5 will import the contents directly to Skynet, giving you peace of mind that your VPN server endpoints are whitelisted.
- ADDED: More checks while determining vpn health, and adding more logic around failed connections, including an indicator showing the number of attempts a certain vpn slot has undergone if it comes back failing the ping and curl tests.
- ADDED: Also, timing delays to allow for tunnels to connect, disconnect and settle have been extended. No, your router hasn't slowed down. I'm just making sure processes aren't stepping over each other to give you the most stable monitoring experience.
- ADDED: When a VPN connection fails, an intermediate 5 second counter will appear allowing you to (P)ause execution. This allows you to enter the Operations Menu, should you need to make any adjustments. I found that with successive failures, it was nearly impossible to get to the Operations menu in order to exclude a certain slot that was causing issues.
- ADDED: Few more log entries for various reset conditions were added.
- FIXED: The timing on connecting, stopping and settling have been dropped slightly. Also, shaved more time by not spending 10 seconds forcing a service_stop on a connection that has already stopped. Likewise, checking for VPN slots in an error (-1) state, and force stopping these, then forcing an NVRAM state reset on them to change them back to 0 (disconnected).
- FIXED: WAN checks were still happening even when disabled. Thanks to @salvo! Fixed!
- FIXED: When the -reset switch is thrown, VPNMON-R3 will immediately drop to the waiting screen. Thanks to @salvo for noticing!
- FIXED: Minor corrections to wording or other on-screen layouts to make the UI more pleasing to the eye.
- FIXED: Made some revisions to how variables were used in order to cut down on some Unknown Operand errors that were initially captured by @Ripshod. Thank you!
Download link:
Code:curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R3/main/vpnmon-r3-1.10.sh" -o "/jffs/scripts/vpnmon-r3.sh" && chmod 755 "/jffs/scripts/vpnmon-r3.sh"
Significant Screenshots:
View attachment 55902
Thanks for the feedback, @CaptainSTX ... that is very strange. Each time a VPN connection drops and reconnects... or if your router reboots, it should reset the time because the VPN connection would need to be started. Hmmm... Do you have your VPN clients auto start on reboot by chance? Perhaps they are starting before R3 has a chance to even start them? So it assumes they were all still running? I guess you can test it by hitting 1/2/3 etc... and seeing if it resets the time for you?Have gone through all the betas and currently running b6. It has kept my three tunnels up and I have eliminated the daily restart. Can see that it is working as now I show variable up times on each tunnel.
Only thing that is a little strange is the uptime on the tunnels exceeds the uptime on the router. I updated to 388.6 three days ago but VPN tunnels show uptime 4, 5 & 6 days. Not an important issue but as I said strange.
Thanks for the great work.
Thanks!Excellent work @Viktor Jaep
Upgraded from the beta and all seems to be running smoothly!
I'll see what I can do!A couple of queries/requests:
- Any chance you could add titanspeed from R2 to R3?
The operations menu is not meant to be a static menu that stays up at all times... When you reset a VPN connection, it actually reloads the script from scratch, so it forgets what was done previously. I'll revisit this and see if a compete reload is truly needed, so standby.- I noticed when I go into some menu options R3 doesn't 'remember' the display setting for the operations menu.
To elaborate more on the second one, at the main menu I typically show the operations menu. If I then issue the V or M commands and return to the main screen, the operations menu is displayed/remembered. If, however I issue a reset via 1, 2, 3 etc. when I return to the main menu, the operations menu is hidden.
Yes I have auto start on reboot selected. I will play around with the clients and see if I can create a situation where router uptime is the same as VPN tunnel uptime. I will turn the automatic restart off for my least used tunnel and then reboot the router and let you know what happens.Thanks for the feedback, @CaptainSTX ... that is very strange. Each time a VPN connection drops and reconnects... or if your router reboots, it should reset the time because the VPN connection would need to be started. Hmmm... Do you have your VPN clients auto start on reboot by chance? Perhaps they are starting before R3 has a chance to even start them? So it assumes they were all still running? I guess you can test it by hitting 1/2/3 etc... and seeing if it resets the time for you?
View attachment 55937
That makes sense for the tunnel uptimes now...Yes I have auto start on reboot selected. I will play around with the clients and see if I can create a situation where router uptime is the same as VPN tunnel uptime. I will turn the automatic restart off for my least used tunnel and then reboot the router and let you know what happens.
Yeah, it doesn't hurt. It's just more for interesting stats purposes... but I'm glad it's performing well for you!I am very satisfied with the way the app works and keeps the tunnels up so while the discrepancy is interesting it doesn't effect its utility.
I tested by disabling automatic restart and if that setting is disabled then the VPN tunnel uptime resets to Zero. I experimented with client 5 Stockholm.That makes sense for the tunnel uptimes now...
Yeah, it doesn't hurt. It's just more for interesting stats purposes... but I'm glad it's performing well for you!
Working as advertised.I tested by disabling automatic restart and if that setting is disabled then the VPN tunnel uptime resets to Zero. I experimented with client 5 Stockholm.
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R3/main/vpnmon-r3-1.11.sh" -o "/jffs/scripts/vpnmon-r3.sh" && chmod 755 "/jffs/scripts/vpnmon-r3.sh"
I think I will leave the setting in place to automatically restart a client on reboot as it is just a second level of backup. Thanks again.Working as advertised.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!