RTRMON RTRMON v1.6.9 -May 3, 2024- Monitor your Router's Health (New: AMTM, Network Conn/Bandwidth/Diag + Port Scanner + Speedtest) [NEW THREAD OPENED]

[Viktor Jaep]

I just checked now. sorry for the delay.

that command returns a "1" when scheduler has the 2.4 band disabled (did I mention this is on my AC86?)

I'm going to assume the logic is different between RTRMON and asuswrt-Merlin and that the radio isn't TRULY disabled unless/until it's de-activated in the GUI... IOW, Standby mode to the firmware and therefore enabled (not disabled) to the script.
It's something you might want to consider working in (if possible) for pedants like me when you're confident functionality is otherwise fully developed...

Forgive my nit-pickiness, with many thanks for your work on this

So I confirmed that when the scheduler activates, the radio is not disabled... it doesn't flip the radio button to "off", and the wl0_radio variable = 1 (enabled) in NVRAM. I found that there's a "sched" variable that now = 1 when you enable the scheduler... but there's nothing in there indicating that the radio/wlan is not accessible. I'm not quite sure how it's preventing traffic from getting on. I'll have to do more of a deep dive to see if somehow it's adding some iptables rules or something? There's a variable that keeps track of the schedule entries, but looks like a PITA to try to decipher in order to determine if <now> falls within the scheduled offtime... Will keep looking into this.

 

[heysoundude]

So I confirmed that when the scheduler activates, the radio is not disabled... it doesn't flip the radio button to "off", and the wl0_radio variable = 1 (enabled) in NVRAM. I found that there's a "sched" variable that now = 1 when you enable the scheduler... but there's nothing in there indicating that the radio/wlan is not accessible. I'm not quite sure how it's preventing traffic from getting on. I'll have to do more of a deep dive to see if somehow it's adding some iptables rules or something? There's a variable that keeps track of the schedule entries, but looks like a PITA to try to decipher in order to determine if <now> falls within the scheduled offtime... Will keep looking into this.

I'd wager there's probably some deep Asus-level stuff that you're going to have a problem getting around - maybe just add the condition "standby" when the scheduler has the radio in standby? but if you want to dig in to the point that your script actually disables and de-powers the 2.4GHZ radio, don't let me stop you.

 

[ColinTaylor]

Interesting! I determine whether or not a radio is on by using this command:

nvram get wl0_radio

If it comes back with "1", then the router considers it to be on?

As you have discovered that only indicates that the radio is "on" rather than "enabled". The scheduler enables/disables the radio using the radio command. Unfortunately there's no simple way of reading its current state (short of parsing the time schedule) as the commands vary depending on the specific router hardware. However, for the majority of Broadcom-radio based routers the following can be used:

# wl -i $(nvram get wl0_ifname) bss
up
# wl -i $(nvram get wl1_ifname) bss
up

HTH

 

[SomeWhereOverTheRainBow]

Our old eyes ain't what they used to be.

Who are you tellin` ?, I can't even see it with my bifocals.

 

[Viktor Jaep]

As you have discovered that only indicates that the radio is "on" rather than "enabled". The scheduler enables/disables the radio using the radio command. Unfortunately there's no simple way of reading its current state (short of parsing the time schedule) as the commands vary depending on the specific router hardware. However, for the majority of Broadcom-radio based routers the following can be used:

# wl -i $(nvram get wl0_ifname) bss
up
# wl -i $(nvram get wl1_ifname) bss
up

HTH

Awesome hack, @ColinTaylor! I'll definitely experiment with this, and see if I make some headway with reporting the correct state!

 

[Viktor Jaep]

Happy New Year!! - small bug fix to v1.51 to squeak in before 2023!

What's new?
v1.51 - (December 31, 2022)
- FIXED: Some logic was causing issues pulling up the NVRAM stats and causing a "malformed ?: operator" full-stop. I am guessing there was a difference between the way 386 reported these stats vs. 388. This fix should be backwards compatible, and was able to test that it continues to work on the old AC86U running 386.7_2.

Download Links (or update directly through AMTM):

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

 

[jtp10181]

Installed 1.51 on AX68U running 388.1 firmware
It has worked at one point but not sure what version was the last working.
As soon as it gets to 100% on the boot sequence I get this error with 1.51 and it exits.

/jffs/scripts/rtrmon.sh: line 3131: arithmetic syntax error

 

[Viktor Jaep]

Installed 1.51 on AX68U running 388.1 firmware
It has worked at one point but not sure what version was the last working.
As soon as it gets to 100% on the boot sequence I get this error with 1.51 and it exits.

/jffs/scripts/rtrmon.sh: line 3131: arithmetic syntax error

View attachment 46842

That's a weird one... would you mind uncommenting the following lines:

2727
2728
3341

Then run the script -- "/jffs/scripts/rtrmon.sh - monitor"

...and then send me the output of when you see the crash? Perhaps that will give me a clue about what it doesn't like about your router/environment.

Thanks!

 

[SomeWhereOverTheRainBow]

Installed 1.51 on AX68U running 388.1 firmware
It has worked at one point but not sure what version was the last working.
As soon as it gets to 100% on the boot sequence I get this error with 1.51 and it exits.

/jffs/scripts/rtrmon.sh: line 3131: arithmetic syntax error

View attachment 46842

So there is a point in the script where an arithmetic operation is not properly being performed eg. $((1+1)) . Maybe a variable is not properly being assigned or parsed. Are you sure you meet the full criteria for running the script?

 

[Viktor Jaep]

So there is a point in the script where an arithmetic operation is not properly being performed eg. $((1+1)) . Maybe a variable is not properly being assigned or parsed. Are you sure you meet the full criteria for running the script?

That's a great observation @SomeWhereOverTheRainBow ... hey @jtp10181 ... would you mind also please including a screenshot of your setup screen, incase there's a value in there it's not expecting?

 

[jtp10181]

Looks like maybe some sort of problem with the swap since those are blank, is it getting a divide by 0 error? I do have a swap file, it is able to be displayed in scMerlin.
I think I know what the issue is, I installed an entware package that has the full "free" command. The output is not the same as the busybox version.
You should explicitly call /usr/bin/free to get the built in BusyBox free command.

 

[jtp10181]

You should explicitly call /usr/bin/free to get the built in BusyBox free command.

Yeap that was it, fixed line 1317 and it works now

    # Disk - Swap file
    swap_use=$($timeoutcmd$timeoutsec /usr/bin/free | awk 'NR==4 {print $2, $3}' 2>/dev/null)

 

[Viktor Jaep]

Looks like maybe some sort of problem with the swap since those are blank, is it getting a divide by 0 error? I do have a swap file, it is able to be displayed in scMerlin.
I think I know what the issue is, I installed an entware package that has the full "free" command. The output is not the same as the busybox version.
You should explicitly call /usr/bin/free to get the built in BusyBox free command.

View attachment 46843

View attachment 46844

View attachment 46845

Nice catch @jtp10181 ... can you validate if you add /usr/bin/free to line 1317, that it will start working again for you? If so, I'll get that added in my next release...

 

[Viktor Jaep]

Yeap that was it, fixed line 1317 and it works now

    # Disk - Swap file
    swap_use=$($timeoutcmd$timeoutsec /usr/bin/free | awk 'NR==4 {print $2, $3}' 2>/dev/null)

You rock. Thanks!!

 

[Viktor Jaep]

Welcome to 2023! Bringing a little new functionality into the New Year with v1.54! Enjoy!

What's new?
v1.54 - (January 3, 2023)
- ADDED: Now giving more visibility to the status of the Wi-Fi scheduler, and showing whether or not the Wi-Fi is up or down based on the scheduler. Please note, when the scheduler disables Wi-Fi for a certain time period, the Wi-Fi itself actually still shows as enabled. Thanks to @heysoundude for the suggestion, and to @ColinTaylor for sharing his wisdom on how to find these particular intriquite settings under NVRAM!
- FIXED: Thanks to @jtp10181 for identifying an issue with the free command, and have inserted an explicit call to /usr/bin/free in case another version of free is present on the system returning invalid info.
- FIXED: Regressed some changes back to v1.50 and implemented some different methods to achieve the same results, as the code I was using was causing some strange results.

Download link (or update directly from within AMTM):

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

Significant Screenshots:
As shown below, each WiFi range will now show (1) if it's Enabled/Disabled, (2) if the Scheduler is Active [+] or Inactive [-], and (3) whether the channel is UP or DOWN based on the scheduler's time block. This info changes dynamically when changes are effectively applied by the scheduler.

 

[heysoundude]

Welcome to 2023! Bringing a little new functionality into the New Year with v1.54! Enjoy!

What's new?
v1.54 - (January 3, 2023)
- ADDED: Now giving more visibility to the status of the Wi-Fi scheduler, and showing whether or not the Wi-Fi is up or down based on the scheduler. Please note, when the scheduler disables Wi-Fi for a certain time period, the Wi-Fi itself actually still shows as enabled. Thanks to @heysoundude for the suggestion, and to @ColinTaylor for sharing his wisdom on how to find these particular intriquite settings under NVRAM!

Slow down, Turbo! I just applied v1.51 last night...

 

[Viktor Jaep]

Slow down, Turbo! I just applied v1.51 last night...

Hey you're welcome! lol

 

[SomeWhereOverTheRainBow]

Hey you're welcome! lol

Must have got the batteries in backwards.

 

[chongnt]

Notice something cosmetic after uninstall.

alias rtrmon="sh /jffs/scripts/rtrmon.sh" # RTRMON

is leftover in /jffs/configs/profile.add

Reinstall to keep it relevant.

 

[Viktor Jaep]

Notice something cosmetic after uninstall.

alias rtrmon="sh /jffs/scripts/rtrmon.sh" # RTRMON

is leftover in /jffs/configs/profile.add

Reinstall to keep it relevant.

Nice catch... Forgot about that one! Thanks @chongnt