VPNMON VPNMON-R2 v2.0 -Jul 10, 2022- Monitor your VPN connection's Health (Thread locked/closed)

[SomeWhereOverTheRainBow]

@Viktor Jaep

I've already reverted from using that, other issues surfaced and May 4th was more than a week ago so suspect any Star Wars effect has worn off ...

Observations from fiddling with it today ...

(1)

Using:-

(sleep 30 && /jffs/scripts/vpnmon-r2.sh -screen) & # vpnmon-r2

in post-mount as suggested by @SomeWhereOverTheRainBow seems to work just as well / identically to my original method of using:-

/jffs/scripts/vpnmon-r2.sh -screen & # vpnmon-r2

with a "sleep 30" added in as the first line of vpnmon-r2.sh, which is to be expected as they SHOULD be equivalent?

HOWEVER confirmed that using your built-in Startup Delay parameter (set to 30) DOES NOT give the same result at present - other AMTM scripts "fail to launch" properly

(2)

Although I said before that the revised Beta 4 was happily detecting WAN Down and WAN Up events and restarting the monitoring, upon further testing it only seem to do it ONCE, that is the first time a WAN Down/Up event occurs after a reboot and my auto-run (called from post-mount)!

The second time I simulate a WAN Down by powering off my cable modem, vpnmon-r2.sh never gets to the "red" screen telling you to reconnect/reboot your modem, no matter how long I wait. I've tried this a couple of times from cold boots of the RT-AX86U just to double-check and appears to be repeatable! Mystified by this one. Can you duplicate my findings or am I going crazy (again)?

(3)

I also note an error message as follows on the "first" monitor cycle iteration after the re-detect of the "WAN Up"

grep: bad regex '\b(*error*|Undefined)\b': Invalid preceding regular expression

Also see screenshot:-

View attachment 41295

Not sure if that is anything to do with anything, on the next monitor "loop" it doesn't appear again and all seems to work?

I also don't know if it is has anything with my point (2) above, but I guess it could be related?

Yea sometimes you will see that if the regular expression doesn't find a match with the string. The hope was that the q extension would always be quiet in this regard, I guess not.

 

[SomeWhereOverTheRainBow]

@Viktor Jaep

I've already reverted from using that, other issues surfaced and May 4th was more than a week ago so suspect any Star Wars effect has worn off ...

Observations from fiddling with it today ...

(1)

Using:-

(sleep 30 && /jffs/scripts/vpnmon-r2.sh -screen) & # vpnmon-r2

in post-mount as suggested by @SomeWhereOverTheRainBow seems to work just as well / identically to my original method of using:-

/jffs/scripts/vpnmon-r2.sh -screen & # vpnmon-r2

with a "sleep 30" added in as the first line of vpnmon-r2.sh, which is to be expected as they SHOULD be equivalent?

HOWEVER confirmed that using your built-in Startup Delay parameter (set to 30) DOES NOT give the same result at present - other AMTM scripts "fail to launch" properly

(2)

Although I said before that the revised Beta 4 was happily detecting WAN Down and WAN Up events and restarting the monitoring, upon further testing it only seem to do it ONCE, that is the first time a WAN Down/Up event occurs after a reboot and my auto-run (called from post-mount)!

The second time I simulate a WAN Down by powering off my cable modem, vpnmon-r2.sh never gets to the "red" screen telling you to reconnect/reboot your modem, no matter how long I wait. I've tried this a couple of times from cold boots of the RT-AX86U just to double-check and appears to be repeatable! Mystified by this one. Can you duplicate my findings or am I going crazy (again)?

(3)

I also note an error message as follows on the "first" monitor cycle iteration after the re-detect of the "WAN Up"

grep: bad regex '\b(*error*|Undefined)\b': Invalid preceding regular expression

Also see screenshot:-

View attachment 41295

Not sure if that is anything to do with anything, on the next monitor "loop" it doesn't appear again and all seems to work?

I also don't know if it is has anything with my point (2) above, but I guess it could be related?

The condition you are referring to in the loop sounds like it may be variable trickery. One way to avoid this is to define variables as local before they are called within the subshell they run otherwise you will literally have to unset them at the end of the same subshell run. Failing to do either sometimes leaves the variable the same as it was the previous run, thus why the wan never goes down because the variable is never unset once it goes down. This means the detection mechanism is using the same variable value established when the wan went up the first time, and never changes when you simulate the wan going down because the previous value was never unset at the end of the prior run meaning it held its value.

 

[dave14305]

Yea sometimes you will see that if the regular expression doesn't find a match with the string. The hope was that the q extension would always be quiet in this regard, I guess not.

You guys need to do something with the asterisks around the word "error". Are they meant to be literal, or wildcards? If literal, escape them with \*error\* or else just remove the asterisks.

 

[SomeWhereOverTheRainBow]

You guys need to do something with the asterisks around the word "error". Are they meant to be literal, or wildcards? If literal, escape them with \*error\* or else just remove the asterisks.

Suppose to be wildcards, so I take it the asterisks are not needed if we are just looking for reference of error despite whatever the before and after are?

 

[Stephen Harrington]

This means the detection mechanism is using the same variable value established when the wan went up the first time, and never changes when you simulate the wan going down because the previous value was never unset at the end of the prior run meaning it held its value.

If that is the case it would certainly explain what I’m seeing … I was hoping someone could confirm they are getting the same result.

 

[SomeWhereOverTheRainBow]

If that is the case it would certainly explain what I’m seeing … I was hoping someone could confirm they are getting the same result.

I am pretty sure it is the case because if you don't localise the non-global variable at the beginning of the subshell run or unset the variable at the end of the subshell run the variable becomes fixed and subsequent runs will repeat the fixed variable instead of introducing the new value. (i.e. if the variable is not intended to remain the same after the first run of the subshell, then the ideal situation would be to unset the variable before subsequent runs of that subshell are made.)

 

[iTyPsIDg]

Suppose to be wildcards, so I take it the asterisks are not needed if we are just looking for reference of error despite whatever the before and after are?

In that case, it needs to be .*.

In regex, a period is a wildcard, and an asterisk means zero or more. Also, you probably want to move it outside of your capture group (the parenthesis).

 

[iTyPsIDg]

If that is the case it would certainly explain what I’m seeing … I was hoping someone could confirm they are getting the same result.

I had an extended power outage last night; however, my router and cable modem are connected to a UPS. The entire area went out, so whatever box the cable modem connected to stopped providing internet. I can confirm that when the WAN came back up, I was stuck at "checking WAN" in the script.

 

[SomeWhereOverTheRainBow]

In that case, it needs to be .*.

In regex, a period is a wildcard, and an asterisk means zero or more. Also, you probably want to move it outside of your capture group (the parenthesis).

So you mean something like
if $VPNCITY | grep -qE '\b(.*error.*|Undefined)\b' 2>/dev/null; then VPNCITY="$ICANHAZIP"; else VPNCITY="$(eval $VPNCITY)"; fi

Would work

 

[dave14305]

So you mean something like
if $VPNCITY | grep -qE '\b(.*error.*|Undefined)\b' 2>/dev/null; then VPNCITY="$ICANHAZIP"; else VPNCITY="$(eval $VPNCITY)"; fi

Would work

That would also match the word “terrors” as an example.

 

[SomeWhereOverTheRainBow]

That would also match the word “terrors” as an example.

We can't have our city names terrors..... so I don't think that is a bad thing lol.

 

[iTyPsIDg]

So you mean something like
if $VPNCITY | grep -qE '\b(.*error.*|Undefined)\b' 2>/dev/null; then VPNCITY="$ICANHAZIP"; else VPNCITY="$(eval $VPNCITY)"; fi

Would work

Yes.

FYI - I love using RegEx 101 to test my expressions. If you are simply looking for the word error or Undefined anywhere in the expression, I would suggest: .*\b(error|Undefined)\b.*.

It looks like you may not need to capture the error or Undefined, so you could even use this: .*\b(?:error|Undefined)\b.*

 

[Viktor Jaep]

Yes.

FYI - I love using RegEx 101 to test my expressions. If you are simply looking for the word error or Undefined anywhere in the expression, I would suggest: .*\b(error|Undefined)\b.*.

It looks like you may not need to capture the error or Undefined, so you could even use this: .*\b(?:error|Undefined)\b.*

Wow... you guys are awesome!! Thanks for the insight on regex...

This is the error that will come across every so often from the API that I'm trying to zero in on and identify. I thought picking up on the word "error" would have been a good first step:

{'error': True, 'reason': 'RateLimited', 'message': 'Visit https://ipapi.co/ratelimited/ for details'}Dallas

The other time you see something funny is when the IP doesn't translate into a city, and it will just spit back the world "Undefined"

 

[Viktor Jaep]

If that is the case it would certainly explain what I’m seeing … I was hoping someone could confirm they are getting the same result.

Steve... I actually tried 3 different attempts this morning to duplicate this issue... basically killing the modem, letting VPNMON-R2 recover, killing it again, recover, etc. One time I did it 3x in a row, but each time, it identified that the WAN went down, sat at the "WAN DOWN" waiting page, and recovered when it came back up. I will continue to dive into this and test this. I have not found any issue where it gets hung up after a second outage.

 

[Viktor Jaep]

So you mean something like
if $VPNCITY | grep -qE '\b(.*error.*|Undefined)\b' 2>/dev/null; then VPNCITY="$ICANHAZIP"; else VPNCITY="$(eval $VPNCITY)"; fi

Would work

Thanks for helping with this fix, @SomeWhereOverTheRainBow, @iTyPsIDg and @dave14305! I'll publish another update later this evening for another round of testing on my end as I relentlessly kill my internet connection. Lol

 

[Viktor Jaep]

I had an extended power outage last night; however, my router and cable modem are connected to a UPS. The entire area went out, so whatever box the cable modem connected to stopped providing internet. I can confirm that when the WAN came back up, I was stuck at "checking WAN" in the script.

So maybe I need to change my own testing strategy... I won't power down my modem, but will unplug it from the ISP end instead to simulate this. I'm curious to find out what exactly "nvram get wan0_state_t" truly gives me if there's still power going to the modem. Thanks for the feedback on this!

 

[SomeWhereOverTheRainBow]

So maybe I need to change my own testing strategy... I won't power down my modem, but will unplug it from the ISP end instead to simulate this. I'm curious to find out what exactly "nvram get wan0_state_t" truly gives me if there's still power going to the modem. Thanks for the feedback on this!

Some observations you should see is that without powering down, on the second go around of pulling the ethernet cable you should see your wan check will still show old results of connected while the cable is unplugged. Atleast that is the gist of the reported behavior.

You may want to confirm the variable

wandownbreakertrip

Is actually changing the way you need it to.

The use of echo can indicate its value at the time it is suppose to change values. I recommend testing with an echo that this value actually changes everything you invoke it to change.

 

[Stephen Harrington]

I will continue to dive into this and test this. I have not found any issue where it gets hung up after a second outage.

Ok thanks. Definitely repeatable here on my setup. Just to confirm, when I test I’m physically cutting power to my cable modem (and then later plugging it back). Asus GUI initially says “Cable Disconnected”.

 

[SomeWhereOverTheRainBow]

Ok thanks. Definitely repeatable here on my setup. Just to confirm, when I test I’m physically cutting power to my cable modem (and then later plugging it back). Asus GUI initially says “Cable Disconnected”.

So play-by-play what happens?


On the first time it tells your WAN is down and when it reconnects, but on the second attempt it doesn't detect your wan as being down? ( assuming no reboots inbetween and no restarts of the process....)

 

[Stephen Harrington]

but on the second attempt it doesn't detect your wan as being down?

Correct, it never gets to the "WAN Down" screen of red text saying "reboot or reconnect your modem" (can't quite remember exact wording), it just sits at the normal monitoring loop screen trying to detect WAN but never going further ...