RTRMON RTRMON v2.1.3 -Oct 19, 2024- Monitor your Router's Health (New: AMTM, Network Conn/Bandwidth/Diag + Port Scanner + Speedtest)

[visortgw]

@Viktor Jaep : Same results with clean install of v2.0.14RC (i.e., broken).

 

[Viktor Jaep]

Breaks again. Let me try uninstall, and reinstall.

So beta 2 works... or does it break too? The RC is working on both my GT-AX6000 and RT-AX88U without issue.

If you want to try a debug, please uncomment these lines:

4658 -- #} #2>&1 | tee $LOG | logger -t $(basename $0)[$$] # uncomment/comment to enable/disable debug mode

3687 -- #DEBUG=; set -x # uncomment/comment to enable/disable debug mode
3688 -- #{ # uncomment/comment to enable/disable debug mode


Then try running it, and please send me the results of where it gets stuck?

 

[visortgw]

So beta 2 works... or does it break too? The RC is working on both my GT-AX6000 and RT-AX88U without issue.

If you want to try a debug, please uncomment these lines:

4658 -- #} #2>&1 | tee $LOG | logger -t $(basename $0)[$$] # uncomment/comment to enable/disable debug mode

3687 -- #DEBUG=; set -x # uncomment/comment to enable/disable debug mode
3688 -- #{ # uncomment/comment to enable/disable debug mode


Then try running it, and please send me the results of where it gets stuck?

Yes, beta 2 works! Give me a few minutes for to enable debug.

 

[visortgw]

SO... It appears that a site-to-site OpenVPN connection (using VPN Director rules) is the culprit (FYI, I changed the site URL to server.site.com for security purposes):

+ VPNState=2
+ [ -z 2 ]
+ [ 2 -eq 2 ]
+ TUN=tun11
+ timeout 10 nvram get vpn_client1_addr
+ NVRAMVPNADDR=server.site.com
+ ping -c 1 -W 0 server.site.com
+ awk -F [()] /PING/ { print $2}

 

[Viktor Jaep]

SO... It appears that a site-to-site OpenVPN connection (using VPN Director rules) is the culprit (FYI, I changed the site URL to server.site.com for security purposes):

+ VPNState=2
+ [ -z 2 ]
+ [ 2 -eq 2 ]
+ TUN=tun11
+ timeout 10 nvram get vpn_client1_addr
+ NVRAMVPNADDR=server.site.com
+ ping -c 1 -W 0 server.site.com
+ awk -F [()] /PING/ { print $2}

Hum... and it just hangs there, eh? I did make a small change to the ping command... let me revert that back and see if that allows it to work again for you. DANG.

 

[visortgw]

Hum... and it just hangs there, eh? I did make a small change to the ping command... let me revert that back and see if that allows it to work again for you. DANG.

... but it explains why yours works and mine does not!

 

[Viktor Jaep]

SO... It appears that a site-to-site OpenVPN connection (using VPN Director rules) is the culprit (FYI, I changed the site URL to server.site.com for security purposes):

OK... see if this RC works better for you. Changed "-W 0" back to "-w 1" on the ping commands.

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/RTRMON/develop/rtrmon.sh" -o "/jffs/scripts/rtrmon.sh" && chmod 755 "/jffs/scripts/rtrmon.sh"

 

[Viktor Jaep]

... but it explains why yours works and mine does not!

Thank goodness for saved revisions... and debug mode. And awesome testers like YOU! LOL

 

[visortgw]

Thank goodness for saved revisions... and debug mode. And awesome testers like YOU! LOL

BINGO!!! That works!

 

[visortgw]

OK... see if this RC works better for you. Changed "-W 0" back to "-w 1" on the ping commands.

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/RTRMON/develop/rtrmon.sh" -o "/jffs/scripts/rtrmon.sh" && chmod 755 "/jffs/scripts/rtrmon.sh"

Please educate me as to the intended difference between the two ping commands.

 

[Viktor Jaep]

Please educate me as to the intended difference between the two ping commands.

I was hoping to shave a little more time off the calculation loop... my hope was that a -W 0 would spend no time moving on after it got a ping... it sounds to me like -w 1 could take up to a second to get its info. But in your case with the site-to-site, something else must be going on.

-w deadline Specify a timeout, in seconds, before ping exits regardless of how many packets have been sent or received. In this case ping does not stop after count packet are sent, it waits either for deadline expire or until count probes are answered or for some error notification from network.

-W timeout Time to wait for a response, in seconds. The option affects only timeout in absense of any responses, otherwise ping waits for two RTTs.

Thanks to your findings (also), I will also need to add a "Known issues" section to the OP that states that if an "s" key is pressed outside the normal interval cycle while it's doing calculations and VPN tunnel checks, that there's a good chance it will kill the script with the "malformed operator" error. Still no luck getting a fix in place for this.

 

[visortgw]

I was hoping to shave a little more time off the calculation loop... my hope was that a -W 0 would spend no time moving on after it got a ping... it sounds to me like -w 1 could take up to a second to get its info. But in your case with the site-to-site, something else must be going on.

-w deadline Specify a timeout, in seconds, before ping exits regardless of how many packets have been sent or received. In this case ping does not stop after count packet are sent, it waits either for deadline expire or until count probes are answered or for some error notification from network.

-W timeout Time to wait for a response, in seconds. The option affects only timeout in absense of any responses, otherwise ping waits for two RTTs.

I believe that I have pings disabled on the distant site, which might help to explain the difference between you and me.

 

[Viktor Jaep]

I believe that I have pings disabled on the distant site, which might help to explain the difference between you and me.

That probably explains things...

 

[visortgw]

That probably explains things...

... but, it is a more secure configuration.

 

[Viktor Jaep]

... but, it is a more secure configuration.

I will double-down on my security stance, thank-you-very-much! Not only do I have all my important passwords saved in @Tech9's password manager, but he also mirrors my private WAN IP to inform me of any security issues. Any he, unbeknownst to me, checks my code during weird hours of the night on my local LAN.

 

[Tech9]

Any he, unbeknownst to me, checks my code during weird hours of the night on my local LAN.

I was actually doing it right now. Sorry, will stop by later. Continue doing what you were doing. The mouse is yours.

 

[Viktor Jaep]

The mouse is yours.

FINALLY. Thanks!

 

[Viktor Jaep]

It's time to bite the bullet and set this puppy free! Huge thanks to @visortgw for all his testing on this, without whom this release would not be possible! Also, again, huge thanks to @nzwayne for dodging bullets loading the Alpha 1 on his GT-BE98 PRO, and making sure RTRMON performs like it should with its new TWIN 6GHz WiFi ranges! Really happy to announce compatibility with the new routers that @RMerlin recently announced: The GT-BE98, RT-BE96U, and GT-BE98 PRO! But that's not all... RTRMON has gone through a huge facelift, bringing it up to current standards, in line with VPNMON-R3, BACKUPMON, and TAILMON. Easier-to-use menus, better visuals, the look and feel overall feels like a whole new script. Enjoy!

What's new! (Better question, what isn't new!)
v2.0.15 - (June 1, 2024)
- MAJOR: Brought RTRMON up to the new visual standards in use across VPNMON-R3, TAILMON and BACKUPMON. All screens have been resized for the more "wide-screen" look, allowing me to condense information, and make better use of screen space. This also includes an operations menu which you can show/hide in order to capitalize on even more screen space in much of the same way VPNMON-R3 functions. It just feels like a whole new script!
- PATCH: In previous versions, only 2 VPN slots would be presented with relevant info. In today's version, up to 5 different VPN slots are displayed depending on which ones are in use.
- PATCH: In previous versions, you could only run a speedtest against your first VPN connection. In this release, you can indicate whether to run a speedtest against any of your up to 5 VPN slots.
- PATCH: Previously, when WiFi interfaces turn on or shut off, they would not be represented in RTRMON as doing such, and would require a restart of RTRMON to see the current WiFi state. Now, the WiFi interfaces reflect reality in realtime.
- PATCH: Prevously, the iftop network stats would only gather WAN, LAN and the first available VPN slot. Page 6 (network/bandwidth stats) now queries and displays all VPN connection info.
- PATCH: Added some additional information on page 1: Total Available RAM, and Total Swap File Size.
- PATCH: On the Network Diagnostics page, RTRMON is now showing a preview of the test command involved in determining if a function works or not. This gives more insight as to the command, IP or network address that the test is attempting to connect to.
- PATCH: Added a new item (12) under the Configuration menu that allows you to specify whether the router that RTRMON is running on is an iMesh Node, AP, Repeater or Bridge. In these operating modes, the eth0 interface is most likely not being used, and will no longer be reporting on or capturing any WAN0 traffic in the RTRMON UI.
- PATCH: Added a new item (13) under the Configuration menu that allows you to specify how large you want your log file to reach. The default is currently 2000 rows, which would give you many months of log data.
- PATCH: After getting some nvram feedback from @visortgw and @dave14305, I've made more modifications on how to determine if a router is truly a router, not an AP/Repeater/iMesh Node. This version is now compliant in supporting routers in these particular configurations.
- PATCH: Through testing with @visortgw, it was determined that the nslookup diag command does not work on iMesh nodes, and made a small modification to it so that it may hopefully pass this test.
- PATCH: Now proudly includes compatibility for the newly announced supported Asus-Merlin FW routers: the GT-BE98_PRO, RT-BE96U and GT-BE98. The BE98_PRO is the first router that makes use of two distinct 6GHz ranges requiring new capabilities from RTRMON! Huge thanks to @nzwayne for installing the Alpha on his GT-BE98_PRO and making sure RTRMON worked flawlessly on it! Also, many thanks to @GNUton for his help determining Wifi interface ranges on the GT-BE98!
- PATCH: Logging standards have been updated across the script, and open to suggestions for other log events that might be reported on.
- PATCH: Implemented the -now switch functionality, giving you the ability to bypass the 5 second SCREEN utility instructions and timer. This functionality works inconjunction with being able to specify which page (1-6) you want to jump to. Examples: "rtrmon -screen -now", "rtrmon -screen 2 -now". The second example would jump to page 2 using screen with no wait.
- PATCH: With many thanks to @nzwayne for allowing us some time to play with his GT-BE98_Pro, and making sure RTRMON is fully compatible with the new dual 6GHz bands, we have worked through all issues! Wanted to say how much I truly appreciate SNB Forum members like @nzwayne for jumping in, being willing to sacrifice his router and load the latest Merlin FW Alpha version on there to ensure compatibility. You rock!
- PATCH: After some debug/testing with @visorgtw, it was determined that a change to the ping command needed to be reverted due to site-to-site VPNs not returning pings as expected. Huge thanks for his great help testing this on his various pieces of router and iMesh-configured equipment!

Download link (or update directly within RTRMON or AMTM):

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/RTRMON/master/rtrmon.sh" -o "/jffs/scripts/rtrmon.sh" && chmod 755 "/jffs/scripts/rtrmon.sh"

Significant Screenshots:

All screens are new... there are more in the [OP]... Enjoy!

Particularly impressive is the WiFi page for the GT-BE98 PRO showing those beefy 2 x 6GHz bands... thanks to @nzwayne for sharing this!

 

[visortgw]

@Viktor Jaep: Question with v2.0.15 for GT-AX6000 router with site-to-site VPN (OpenVPN and VPN Director). If I select Refresh (C) Current Statistics, it takes about 8 seconds for WAN, 7 seconds for LAN, and 4 minutes 34 seconds for VPN — VPN1 (site-to-site) results in No Data. Any idea why VPN stats take so much time, only to return No Data?

 

[Viktor Jaep]

@Viktor Jaep: Question with v2.0.15 for GT-AX6000 router with site-to-site VPN (OpenVPN and VPN Director). If I select Refresh (C) Current Statistics, it takes about 8 seconds for WAN, 7 seconds for LAN, and 4 minutes 34 seconds for VPN — VPN1 (site-to-site) results in No Data. Any idea why VPN stats take so much time, only to return No Data?

I have this feeling in the back of my head that it might be because of your site-to-site setup... let me take a look at the code. Could you verify that the IP on the other end is a private IP? Perhaps I can just exclude this from being able to run when it hits a private IP.

Would be interesting to see what results you get from:

iftop -i tun1x  (where x = the VPN slot# you want to listen to)