amtm amtm 6.0.1 - the Asuswrt-Merlin Terminal Menu, May 31, 2025

[visortgw]

In other words, the Aura RGB coupling in lc is useless and can be removed as long as my logic in lc reinstates the correct setting as set in the WebUI. Right?

That makes sense...

 

[thelonelycoder]

amtm 6.0.1 is now available

• Reworked LED control lc to work with wifi7, wifi6 and older firmware.

This removes the ineffective Aura RGB coupling feature in lc.
Instead, LED control mirrors the Aura RGB settings made in the WebUI on ROG routers supporting this feature.
The current Aura theme is shown in lc, along with the Dark Mode setting (if supported).

 

[maghuro]

amtm 6.0.1 is now available

• Reworked LED control lc to work with wifi7, wifi6 and older firmware.

This removes the ineffective Aura RGB coupling feature in lc.
Instead, LED control mirrors the Aura RGB settings made in the WebUI on ROG routers supporting this feature.
The current Aura theme is shown in lc, along with the Dark Mode setting (if supported).

Well done! Everything's good right now. Thank you

 

[visortgw]

Same here — works both on GT-BE98 Pro primary router and GT-AX6000 AiMesh nodes.

 

[pdc]

It's working for me! Thanks for all your hard work!

 

[visortgw]

@thelonelycoder: I reinstalled Merlin 3006.102.4 on my GT-AXE16000 AiMesh node. I subsequently installed amtm, entware, and LED control (lc). I discovered a small anomaly with the primary LED behavior. The GT-AXE16000 has four (4) LED indicators for the WiFi bands (i.e., 6 GHz, 5 GHz-1, 5 GHz-2, and 2.4 GHz). When I manually disable the LEDs via lc, the second WiFi LED from the left (one of the two 5 GHz LEDs) remains lit while all of the remaining LEDs and Aura RGB go dark.

Any thoughts on this? Any nvram dumps that might help?

 

[Viktor Jaep]

@thelonelycoder: I reinstalled Merlin 3006.102.4 on my GT-AXE16000 AiMesh node. I subsequently installed amtm, entware, and LED control (lc). I discovered a small anomaly with the primary LED behavior. The GT-AXE16000 has four (4) LED indicators for the WiFi bands (i.e., 6 GHz, 5 GHz-1, 5 GHz-2, and 2.4 GHz). When I manually disable the LEDs via lc, the second WiFi LED from the left (one of the two 5 GHz LEDs) remains lit while all of the remaining LEDs and Aura RGB go dark.

Any thoughts on this? Any nvram dumps that might help?

This might?

 

[thelonelycoder]

@thelonelycoder: I reinstalled Merlin 3006.102.4 on my GT-AXE16000 AiMesh node. I subsequently installed amtm, entware, and LED control (lc). I discovered a small anomaly with the primary LED behavior. The GT-AXE16000 has four (4) LED indicators for the WiFi bands (i.e., 6 GHz, 5 GHz-1, 5 GHz-2, and 2.4 GHz). When I manually disable the LEDs via lc, the second WiFi LED from the left (one of the two 5 GHz LEDs) remains lit while all of the remaining LEDs and Aura RGB go dark.

Any thoughts on this? Any nvram dumps that might help?

Did you do the full L&LD dance? /s

 

[maghuro]

I just noticed the new text: Aura Night Mode set in WebUI: On

What is Aura night mode on webui? I can't find that option in my gt-ax6000 webui, but for some reason amtm says it's on

 

[thelonelycoder]

I just noticed the new text: Aura Night Mode set in WebUI: On

What is Aura night mode on webui? I can't find that option in my gt-ax6000 webui, but for some reason amtm says it's on

A remnant of the removed Aura RGB coupling that it set when enabled.
This feature dims the Aura LEDs on routers supporting it, like my GT-BE98.
No harm, the firmware on your router just ignores the variable.

Your GT-AX6000 does not have that feature. To correct this blatant lie, run this in the terminal, the Night Mode setting will disappear in lc:

nvram set ledg_night_mode=
nvram commit

Warning: Running the above command on a router that actually supports the Night Mode makes the setting go away in the WebUI!
If so, just run this, 0 = Dark Mode off, 1 = on:

nvram set ledg_night_mode=0
nvram commit

 

[thelonelycoder]

@thelonelycoder: I reinstalled Merlin 3006.102.4 on my GT-AXE16000 AiMesh node. I subsequently installed amtm, entware, and LED control (lc). I discovered a small anomaly with the primary LED behavior. The GT-AXE16000 has four (4) LED indicators for the WiFi bands (i.e., 6 GHz, 5 GHz-1, 5 GHz-2, and 2.4 GHz). When I manually disable the LEDs via lc, the second WiFi LED from the left (one of the two 5 GHz LEDs) remains lit while all of the remaining LEDs and Aura RGB go dark.

Any thoughts on this? Any nvram dumps that might help?

Seriously now, this is the GT-BE98, all leds off:

paperweight@GT-BE98-A804:/tmp/home/root# nvram show | sort | grep '^led_\|ledg_\|AllLED'
size: 173277 bytes (88867 left)
AllLED=0
AllLED_brightness=255
led_10g_white_gpio=4143
led_2g_gpio=255
led_5g_gpio=255
led_afc_gpio=4144
led_all_gpio=255
led_ctrl_cap=4
led_disable=1
led_extphy_gpio=255
led_group1_blue_gpio=3
led_group1_green_gpio=4
led_group1_red_gpio=2
led_group2_blue_gpio=7
led_group2_green_gpio=8
led_group2_red_gpio=5
led_group3_blue_gpio=15
led_group3_green_gpio=16
led_group3_red_gpio=14
led_lan1_gpio=255
led_lan2_gpio=255
led_lan3_gpio=255
led_lan4_gpio=255
led_lan_gpio=4097
led_logo_gpio=255
led_pwr_gpio=4146
led_turbo_gpio=255
led_usb3_gpio=255
led_usb_gpio=255
led_val=1
led_wan_gpio=4139
led_wan_normal_gpio=4113
led_wps_gpio=255
ledg_led_enable=1
ledg_new_default_rgb=
ledg_new_default_scheme=5
ledg_night_mode=0
ledg_night_rgb1=10,0,0,12,0,3,10,0,12
ledg_night_rgb2=1,0,0,1,0,0,1,0,0
ledg_night_rgb3=50,0,0,58,0,32,50,0,64
ledg_night_rgb7=50,0,0,58,0,32,50,0,64
ledg_qis_finish=1
ledg_rgb1=100,0,0,120,0,30,100,0,128
ledg_rgb2=0,22,128,0,22,128,0,22,128
ledg_rgb3=100,0,0,120,0,40,100,0,128
ledg_rgb6=100,0,0,120,0,30,100,0,128
ledg_rgb7=100,0,0,120,0,40,100,0,128
ledg_scheme=0
ledg_scheme_old=5
ledg_sdn=0<0<0

While this is with leds on:

paperweight@GT-BE98-A804:/tmp/home/root# nvram show | sort | grep '^led_\|ledg_\|AllLED'
size: 173345 bytes (88799 left)
AllLED=1
AllLED_brightness=255
led_10g_white_gpio=4143
led_2g_gpio=255
led_5g_gpio=255
led_afc_gpio=4144
led_all_gpio=255
led_ctrl_cap=4
led_disable=0
led_extphy_gpio=255
led_group1_blue_gpio=3
led_group1_green_gpio=4
led_group1_red_gpio=2
led_group2_blue_gpio=7
led_group2_green_gpio=8
led_group2_red_gpio=5
led_group3_blue_gpio=15
led_group3_green_gpio=16
led_group3_red_gpio=14
led_lan1_gpio=255
led_lan2_gpio=255
led_lan3_gpio=255
led_lan4_gpio=255
led_lan_gpio=4097
led_logo_gpio=255
led_pwr_gpio=4146
led_turbo_gpio=255
led_usb3_gpio=255
led_usb_gpio=255
led_val=1
led_wan_gpio=4139
led_wan_normal_gpio=4113
led_wps_gpio=255
ledg_led_enable=1
ledg_new_default_rgb=
ledg_new_default_scheme=5
ledg_night_mode=0
ledg_night_rgb1=10,0,0,12,0,3,10,0,12
ledg_night_rgb2=1,0,0,1,0,0,1,0,0
ledg_night_rgb3=50,0,0,58,0,32,50,0,64
ledg_night_rgb7=50,0,0,58,0,32,50,0,64
ledg_qis_finish=1
ledg_rgb1=100,0,0,120,0,30,100,0,128
ledg_rgb2=0,22,128,0,22,128,0,22,128
ledg_rgb3=100,0,0,120,0,40,100,0,128
ledg_rgb6=100,0,0,120,0,30,100,0,128
ledg_rgb7=100,0,0,120,0,40,100,0,128
ledg_scheme=5
ledg_scheme_old=5
ledg_sdn=0<0<0

Only differences with off an on are AllLED, led_disable and ledg_scheme.

 

[visortgw]

Seriously now, this is the GT-BE98, all leds off:

paperweight@GT-BE98-A804:/tmp/home/root# nvram show | sort | grep '^led_\|ledg_\|AllLED'
size: 173277 bytes (88867 left)
AllLED=0
AllLED_brightness=255
led_10g_white_gpio=4143
led_2g_gpio=255
led_5g_gpio=255
led_afc_gpio=4144
led_all_gpio=255
led_ctrl_cap=4
led_disable=1
led_extphy_gpio=255
led_group1_blue_gpio=3
led_group1_green_gpio=4
led_group1_red_gpio=2
led_group2_blue_gpio=7
led_group2_green_gpio=8
led_group2_red_gpio=5
led_group3_blue_gpio=15
led_group3_green_gpio=16
led_group3_red_gpio=14
led_lan1_gpio=255
led_lan2_gpio=255
led_lan3_gpio=255
led_lan4_gpio=255
led_lan_gpio=4097
led_logo_gpio=255
led_pwr_gpio=4146
led_turbo_gpio=255
led_usb3_gpio=255
led_usb_gpio=255
led_val=1
led_wan_gpio=4139
led_wan_normal_gpio=4113
led_wps_gpio=255
ledg_led_enable=1
ledg_new_default_rgb=
ledg_new_default_scheme=5
ledg_night_mode=0
ledg_night_rgb1=10,0,0,12,0,3,10,0,12
ledg_night_rgb2=1,0,0,1,0,0,1,0,0
ledg_night_rgb3=50,0,0,58,0,32,50,0,64
ledg_night_rgb7=50,0,0,58,0,32,50,0,64
ledg_qis_finish=1
ledg_rgb1=100,0,0,120,0,30,100,0,128
ledg_rgb2=0,22,128,0,22,128,0,22,128
ledg_rgb3=100,0,0,120,0,40,100,0,128
ledg_rgb6=100,0,0,120,0,30,100,0,128
ledg_rgb7=100,0,0,120,0,40,100,0,128
ledg_scheme=0
ledg_scheme_old=5
ledg_sdn=0<0<0

While this is with leds on:

paperweight@GT-BE98-A804:/tmp/home/root# nvram show | sort | grep '^led_\|ledg_\|AllLED'
size: 173345 bytes (88799 left)
AllLED=1
AllLED_brightness=255
led_10g_white_gpio=4143
led_2g_gpio=255
led_5g_gpio=255
led_afc_gpio=4144
led_all_gpio=255
led_ctrl_cap=4
led_disable=0
led_extphy_gpio=255
led_group1_blue_gpio=3
led_group1_green_gpio=4
led_group1_red_gpio=2
led_group2_blue_gpio=7
led_group2_green_gpio=8
led_group2_red_gpio=5
led_group3_blue_gpio=15
led_group3_green_gpio=16
led_group3_red_gpio=14
led_lan1_gpio=255
led_lan2_gpio=255
led_lan3_gpio=255
led_lan4_gpio=255
led_lan_gpio=4097
led_logo_gpio=255
led_pwr_gpio=4146
led_turbo_gpio=255
led_usb3_gpio=255
led_usb_gpio=255
led_val=1
led_wan_gpio=4139
led_wan_normal_gpio=4113
led_wps_gpio=255
ledg_led_enable=1
ledg_new_default_rgb=
ledg_new_default_scheme=5
ledg_night_mode=0
ledg_night_rgb1=10,0,0,12,0,3,10,0,12
ledg_night_rgb2=1,0,0,1,0,0,1,0,0
ledg_night_rgb3=50,0,0,58,0,32,50,0,64
ledg_night_rgb7=50,0,0,58,0,32,50,0,64
ledg_qis_finish=1
ledg_rgb1=100,0,0,120,0,30,100,0,128
ledg_rgb2=0,22,128,0,22,128,0,22,128
ledg_rgb3=100,0,0,120,0,40,100,0,128
ledg_rgb6=100,0,0,120,0,30,100,0,128
ledg_rgb7=100,0,0,120,0,40,100,0,128
ledg_scheme=5
ledg_scheme_old=5
ledg_sdn=0<0<0

Only differences with off an on are AllLED, led_disable and ledg_scheme.

That seems consistent with mine on the GT-AXE16000.

But someone must've done some full dance overnight. My entware installation on the device didn't seem to be active this morning when I tried to configure lc (i.e., dynamic time configuration grayed out). Possibly flaky USB flash drive? I replaced USB flash drive, and reconfigured lc — it works as expected now (no orphan 5G WiFi LED remaining lit when LEDs manually disabled). Doesn't really make sense, but I have no other explanation.

I'll see what happens tonight at sunset (20:35 EDT).

 

[thelonelycoder]

That seems consistent with mine on the GT-AXE16000.

But someone must've done some full dance overnight. My entware installation on the device didn't seem to be active this morning when I tried to configure lc (i.e., dynamic time configuration grayed out). Possibly flaky USB flash drive? I replaced USB flash drive, and reconfigured lc — it works as expected now (no orphan 5G WiFi LED remaining lit when LEDs manually disabled). Doesn't really make sense, but I have no other explanation.

I'll see what happens tonight at sunset (20:35 EDT).

Never be cheap on essentials. As you very well know.
Makes sense as the required Entware binaries were unavailable when lc sets the days cron jobs.
I‘m sure I tested this scenario and have built in exit routes for that while the script runs.

Always something new

 

[visortgw]

Never be cheap on essentials. As you very well know.
Makes sense as the required Entware binaries were unavailable when lc sets the days cron jobs.
I‘m sure I tested this scenario and have built in exit routes for that while the script runs.

Always something new

I use true SSDs on primary router, but flash sticks for the AiMesh nodes.

 

[JGrana]

This might?
View attachment 66047

This would be the non-destructive way:

 

[bennor]

@thelonelycoder, Has it been suggested yet to have some sort of a check for scripts that are not (currently) supported on the 3006.102.x firmware to prevent (or at least warn) someone from installing them or warning if they're already installed when someone migrates from 3004.388.x to 2006.102.x firmware? If not; is such a check and prevention, or clear warning, something worth considering adding if possible?

 

[visortgw]

Never be cheap on essentials. As you very well know.
Makes sense as the required Entware binaries were unavailable when lc sets the days cron jobs.
I‘m sure I tested this scenario and have built in exit routes for that while the script runs.

Always something new

So... It doesn't appear to be a failed USB flash drive. For whatever reason, entware is "disappearing" on three (3) different AiMesh nodes:

• Two (2) GT-AX6000
• One (1) GT-AXE16000
• All with Merlin 3006.102.4 firmware

When I go into amtm following a reboot of the nodes, entware does not appear in the menu. If I enter ep from the amtm main menu, I am prompted to install entware — I am given the option to use the existing entware repository on the flash drive or install new (I selected "new" to avoid any additional anomalies).

I checked /jffs/scripts on one of the three nodes:

TheS1R@GT-AXE16000-B4F0:/tmp/home/root# cd /jffs/scripts/
TheS1R@GT-AXE16000-B4F0:/jffs/scripts# ls -al
drwxr-xr-x    2 TheS1R   root           304 Jun  1 13:52 .
drwxr-xr-x   13 TheS1R   root          2240 Dec 31  2023 ..
-rwxr-xr-x    1 TheS1R   root           129 Jun  1 13:52 post-mount
-rwxr-xr-x    1 TheS1R   root            60 Jun  1 07:14 services-stop
TheS1R@GT-AXE16000-B4F0:/jffs/scripts# cat post-mount
#!/bin/sh
. /jffs/addons/amtm/mount-entware.mod # Added by amtm


/bin/sh /jffs/addons/amtm/led_control.mod -set # Added by amtm
TheS1R@GT-AXE16000-B4F0:/jffs/scripts# cat services-stop
#!/bin/sh

/opt/etc/init.d/rc.unslung stop # Added by amtm

TheS1R@GT-AXE16000-B4F0:/jffs/scripts#

Any thoughts on this? Possibly entware no longer works on AiMesh nodes with 3006.102 firmware?

UPDATE: It appears that the symbolic link for entware in /tmp does not exist. I manually created it using the following command, office being my USB label:

ln -s /tmp/mnt/office/entware /tmp/opt​

Going back into amtm, entware is visible again:

​

What should make that symbolic link persistent?

 

[swejuggalo]

Was this expected to happen after the script update?

View attachment 66019

and strange jump by +0.0.2 versions.... (ignore MerlinAU - its on development-debugging)

View attachment 66020

I installed some AMTM-OSR scripts, and while I forgot exactly what script that triggered it, I also got similar errors (many of them). It eventually stopped. But what I'm sure of is that in my case it was a script I installed (not upgrading it). So, it's not necessarily old vs new database triggered, but database creation.

 

[jksmurf]

UPDATE: It appears that the symbolic link for entware in /tmp does not exist. I manually created it using the following command, office being my USB label:
ln -s /tmp/mnt/office/entware /tmp/opt
Going back into amtm, entware is visible again:

I have entware on a couple of mesh nodes. Was the symbolic link also missing after you reinstalled entware (after selecting ep) or only on your original installs (after the amtm 6.01 update)?

 

[visortgw]

I have entware on a couple of mesh nodes. Was the symbolic link also missing after you reinstalled entware (after selecting ep) or only on your original installs (after the amtm 6.01 update)?

Yes, it was also post-v6.0.1.