VPNMON VPNMON-R3 v1.3.7 -Oct 20, 2024- Monitor WAN/Dual-WAN/OpenVPN Health & Reset Multiple OpenVPN Connections (Now available in AMTM!)

[iTyPsIDg]

I noticed that my city exits are no longer showing up. They simply show up blank. This happens under WAN and VPN.

 

[Ripshod]

Are they blank or do they show [n/a]?

I noticed that my city exits are no longer showing up. They simply show up blank. This happens under WAN and VPN.

 

[cptnoblivious]

Really weird. Works for me immediately on start. I'm starting it from command line...not AMTM.

Thanks Viktor, I'll test launching from terminal when I get back home and report back.
Again, it's not critical in any way, just a small delay. Mostly I posted up to let others know that if this happens to not worry, just wait a couple of minutes.

 

[Rajjco]

Noticed Skynet was blocking ip-api.com which is queried by the script to display ip information in the cli this might be related but not sure.

Here is the alientvault indicator link:
https://otx.alienvault.com/indicator/ip/208.95.112.1

 

[iTyPsIDg]

Are they blank or do they show [n/a]?

Blank

 

[cptnoblivious]

@Viktor Jaep well, I tested it, exiting vpnmon and then re-launching directly from terminal using vpnmon-r3 -screen and it came right up.
Found that strange, so I exited and re-launched via amtm and this time no delay either.

 

[Viktor Jaep]

@Viktor Jaep well, I tested it, exiting vpnmon and then re-launching directly from terminal using vpnmon-r3 -screen and it came right up.
Found that strange, so I exited and re-launched via amtm and this time no delay either.

No words.

 

[Viktor Jaep]

Noticed Skynet was blocking ip-api.com which is queried by the script to display ip information in the cli this might be related but not sure.

Here is the alientvault indicator link:
https://otx.alienvault.com/indicator/ip/208.95.112.1

Exactly... That's probably what was blocking city name lookups.

 

[Martinski]

Again, what it takes is waiting for 2 full cycles and then everything works as normal, as I indicated in my posts

Yeah, I got that from your initial post. That's why I did not say "the script is getting stuck forever within the main loop when gathering the data …" Only that the script appears to be getting "stuck" *while* gathering the data …

IOW, to make it clear, my hypothesis is:

It seems like the script is getting "stuck" temporarily somewhere within the main loop while gathering the data to display on the screen.

 

[Martinski]

I noticed that my city exits are no longer showing up. They simply show up blank. This happens under WAN and VPN.

Noticed Skynet was blocking ip-api.com which is queried by the script to display ip information in the cli this might be related but not sure.
...

Exactly... That's probably what was blocking city name lookups.

This kind of scenario (i.e. empty values) should be easy to handle. I recall there's already some code that checks the results of the curl cmd for specific "failure" strings, but most likely it's not handling NULL strings. I'll take a look while I'm fixing a minor issue that one of my cousins saw yesterday evening WRT incorrect elapsed time percentages when in the main loop.

UPDATE:
----------
I've submitted a PR to the 'develop' branch with the following fixes/improvements:

1) Modified code to handle scenarios where getting the "city exit" value returns an empty/NULL string.

2) Modified code to ignore invalid key presses within the main loop.

3) Added code to prevent updating the timer prematurely within the main loop due to repeatedly fast key presses.

4) Modified code to get elapsed time percentage values with 1 decimal place (e.g. 0.5%)

This allows displaying non-integer values for percentages of the elapsed time.​

The last fix is about showing 0% when the elapsed time was > 0 sec. This was recreated by setting the maximum loop timer to a large value (e.g. 600 sec.)

BEFORE Fix:

AFTER Fix:

 

[Viktor Jaep]

I've submitted a PR to the 'develop' branch with the following fixes/improvements:

Thanks again, @Martinski! I really appreciate you continuing to look into this! I'm excited to take a look to see how you handled the invalid keypresses during the loop part. This has been a major frustration for me, especially in RTRMON. I hope I can duplicate your methods!

The last fix is about showing 0% when the elapsed time was > 0 sec. This was recreated by setting the maximum loop timer to a large value (e.g. 600 sec.)

Ahem... "legitimate rounding errors"??

 

[Martinski]

Thanks again, @Martinski! I really appreciate you continuing to look into this! I'm excited to take a look to see how you handled the invalid keypresses during the loop part. This has been a major frustration for me, especially in RTRMON. I hope I can duplicate your methods!

You're welcome. And, of course, feel free to reuse and port the code over to your other scripts. If you have any questions, you know where to find me.

Ahem... "legitimate rounding errors"??

Yeah, the issue was indeed caused by rounding off to the nearest integer value due to the method used to calculate it. In your particular case, getting a floating point number with one significant decimal place is sufficiently precise and makes it more meaningful to the user (IMO), especially when the maximum loop timer is set to a value much greater than 100 seconds.

RE: "legitimate rounding errors"??
Well... Your "OCD tendencies" might feel differently...

 

[Viktor Jaep]

Again, thank you @Martinski for the welcome changes and fixes! Here's what's new:

What's new:
v1.3.7 - (October 20, 2024)
- PATCH: Modified code to handle scenarios where getting the "city exit" value returns an empty/NULL string.
- PATCH: Modified code to ignore invalid key presses within the main loop.
- PATCH: Added code to prevent updating the timer prematurely within the main loop due to repeatedly fast key presses.
- PATCH: Modified code to get elapsed time percentage values with 1 decimal place (e.g. 0.5%). This allows displaying non-integer values for percentages of the elapsed time.
- PATCH: More minor coding improvements & fine-tuning.
- PATCH: Fixed the Y/N prompts so they now require you to hit <enter> after typing either y or n. This changes its behavior from automatically moving on and possibly causing issues from people also using the enter key accidentally.

Download link:

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R3/main/vpnmon-r3.sh" -o "/jffs/scripts/vpnmon-r3.sh" && chmod 755 "/jffs/scripts/vpnmon-r3.sh"

Significant Screenshots:
Check @Martinski's post for some of these changes:

VPNMON - VPNMON-R3 v1.3.6 -Oct 12, 2024- Monitor WAN/Dual-WAN/OpenVPN Health & Reset Multiple OpenVPN Connections (Now available in AMTM!)

I noticed that my city exits are no longer showing up. They simply show up blank. This happens under WAN and VPN.

www.snbforums.com

 

[Martinski]

Thanks again, @Martinski! I really appreciate you continuing to look into this! I'm excited to take a look to see how you handled the invalid keypresses during the loop part. This has been a major frustration for me, especially in RTRMON. I hope I can duplicate your methods!
...

I got some free time this evening and started to take a look at porting the code from VPNMON-R3 to the RTRMON script to ignore invalid key presses within the timer loops, and I found a syntax error in a printf() call statement. Since the same error is also found in BACKUPMON & VPNMON-R3 scripts I've fixed that code and created a pull request on each GitHub repository. I also made a couple of minor code improvements.

I'll continue to look at porting the code over to RTRMON.

FYI.

 

[Viktor Jaep]

I got some free time this evening and started to take a look at porting the code from VPNMON-R3 to the RTRMON script to ignore invalid key presses within the timer loops, and I found a syntax error in a printf() call statement. Since the same error is also found in BACKUPMON & VPNMON-R3 scripts I've fixed that code and created a pull request on each GitHub repository. I also made a couple of minor code improvements.

I'll continue to look at porting the code over to RTRMON.

FYI.

You must be mistaken! My code is 100% error free! Lol

Thanks @Martinski! I had been working on a key press suppression tactic for some time without luck. A known issue is especially repeatable in rtrmon... Directly after the 10sec loop, and before the loop starts over, it runs through a large set of calculations. During that brief window, if you hit "s", you can frequently make it terminate the script with a "malformed operator" error.

 

[Martinski]

You must be mistaken! My code is 100% error free! Lol

Oh yeah, "Bug-Free Code." The legendary mythical beast, long sought by hardened, battle-scarred developers as well as young novices eager to prove their true mettle. It's been seen only in brief moments, usually during long, energy-drink-and-coffee-laden marathon nights of frenzy coding sessions...

Thanks @Martinski! I had been working on a key press suppression tactic for some time without luck. A known issue is especially repeatable in rtrmon... Directly after the 10sec loop, and before the loop starts over, it runs through a large set of calculations. During that brief window, if you hit "s", you can frequently make it terminate the script with a "malformed operator" error.

You mean the following error?

Yeah, it's the first problem I found during my initial "testing & kicking-the-tires" session to see what problems existed by not ignoring invalid key presses during the timer loops.

I've found other issues as well. For example, when setting the "Timer Interval" option (while testing), the code was taking any user input with little validation (e.g. "0" or "X") and without lower-bound or upper-bound checking, so I was getting runtime errors such as "divide by zero" or "arithmetic syntax error."

Granted, users should know better and never enter invalid values but it's always better (and a recommended standard practice) to validate user input, no matter what.

Anyway, I've already fixed the above 2 problems so things are already working much better. After dinner, I'll run more testing & validation.

 

[Viktor Jaep]

Oh yeah, "Bug-Free Code." The legendary mythical beast, long sought by hardened, battle-scarred developers as well as young novices eager to prove their true mettle. It's been seen only in brief moments, usually during long, energy-drink-and-coffee-laden marathon nights of frenzy coding sessions...

That pretty much sums me up to the T right there... LOL

You mean the following error?

That's the one!

Yeah, it's the first problem I found during my initial "testing & kicking-the-tires" session to see what problems existed by not ignoring invalid key presses during the timer loops.

I've found other issues as well. For example, when setting the "Timer Interval" option (while testing), the code was taking any user input with little validation (e.g. "0" or "X") and without lower-bound or upper-bound checking, so I was getting runtime errors such as "divide by zero" or "arithmetic syntax error."

Granted, users should know better and never enter invalid values but it's always better (and a recommended standard practice) to validate user input, no matter what.

Anyway, I've already fixed the above 2 problems so things are already working much better. After dinner, I'll run more testing & validation.

You are amazing! I can't wait to see how you approached this. I had always figured that because it's a shell script, that keyboard input was just inserting itself into the lengthy calculations running in the background during this time, and the insertion of just 1 character would throw off the math, giving these errors. I was looking for a way to prevent keyboard input altogether just to keep the calculations undisturbed, but never had any luck with that.

 

[Martinski]

.. I had always figured that because it's a shell script, that keyboard input was just inserting itself into the lengthy calculations running in the background during this time, and the insertion of just 1 character would throw off the math, giving these errors.

Well, that's not quite how the interactive session terminal input buffer works and, in this case, how it was causing the errors.

Basically, under normal circumstances, every key press is stored in the standard input buffer (i.e. a FIFO queue) until it reaches its maximum limit (IIRC, 4096 chars), or until the "termination key" is entered, normally the <Enter> key or other key presses (e.g. <Ctrl>C, <Ctrl>D, etc.) The keyboard input was *not* "inserting itself into the lengthy calculations running in the background." Instead, the input buffer is available and can be read by any of the commands being executed by the script that accepts input from stdin and it's not given an alternative input source.

IOW, it was while gathering the data required to calculate the results and display them on the screen that some commands (e.g. top) read the available char(s) from the input buffer and reacted accordingly, which ended up changing the data output by the command, and this led to errors in the subsequent calculations that were performed with the "unexpected" data.

There are some timing issues & other subtle details that I omitted in the above explanation, but essentially that was the gist of the problem.

This evening, I've submitted a PR to your 'develop' branch so you can run your own testing & validation to see if it works well for your router. I've only been using the RTRMON script for a couple of days so I could have missed other points of failure.

HTH.

 

[bibikalka]

@Viktor Jaep

It seems similar keyboard issues could be present in RTRMON - @Martinski here is onto something