What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

amtm amtm 5.2 - the Asuswrt-Merlin Terminal Menu, February 09, 2025

It's the same check.
To be frank, with MerlinAU doing a better job and the current state of the GT-BE Pro and non-Pro firmware release cycle I'm dropping the firmware update check function in amtm. I cannot test it properly with the only GT-BE router available in Switzerland and I am already sick of that router.

amtm will only check for script updates starting with the next release.

That for sure is an easy solution!

Quick and easy way to go about it, I thank you for saying MerlinAU is working well :) @Martinski can fix them faster than I can find them when it comes to new releases.
My only comment will be on behalf of the users that only want to be notified (without doing the updates), they may mention they are sad to see this functionality go and ask you to reconsider :)
However I do appreciate you taking the time anyways to quickly save us from our inboxes, I am sorry to hear that the GT-BE98 isn't working to your satisfaction though.

If you are a user that relied on @thelonelycoder 's update emails to be notified, as he mentioned, you can install MerlinAU and if you don't want it to auto-update, simply disable the Auto-Update Check from the main menu (option 3)* or set a extremely long postpone period, depending on your comfort levels.
 
Last edited:
That for sure is an easy solution!

Quick and easy way to go about it, I thank you for saying MerlinAU is working well :) @Martinski can fix them faster than I can find them when it comes to new releases.
My only comment will be on behalf of the users that only want to be notified (without doing the updates), they may mention they are sad to see this functionality go and ask you to reconsider :)
However I do appreciate you taking the time anyways to quickly save us from our inboxes, I am sorry to hear that the GT-BE98 isn't working to your satisfaction though.

If you are a user that relied on @thelonelycoder 's update emails to be notified, as he mentioned, you can install MerlinAU and if you don't want it to auto-update, simply disable the Auto-Update Check from the main menu (option 3)* or set a extremely long postpone period, depending on your comfort levels.
The fw firmware update notification is still available in amtm. Just not within the u update check.
 
The fw firmware update notification is still available in amtm. Just not within the u update check.

Ah! Fantastic, thank you for that additional clarification. I should grab a coffee 😉
 
Last edited:
AMTM 5.2, RT-AX-86U Pro, Merlin 3004.388.8_4

When using AMTM it lists the date and UTC. The UTC is showing local time and not UTC. Where I'm at UTC is -6. Should the time show as local or UTC?
 
Post the output of:
Code:
nvram get time_zone_x
ls -l /etc/localtime
date

admin@RT-AX86U_Pro:/tmp/home/root# nvram get time_zone_x
UTC6DST,M3.2.0/2,M11.1.0/2
admin@RT-AX86U_Pro:/tmp/home/root# ls -l /etc/localtime
lrwxrwxrwx 1 admin root 34 Nov 21 11:57 /etc/localtime -> /rom/usr/share/zoneinfo/US/Central
admin@RT-AX86U_Pro:/tmp/home/root# date
Sun Feb 23 18:11:46 CST 2025
 
admin@RT-AX86U_Pro:/tmp/home/root# nvram get time_zone_x
UTC6DST,M3.2.0/2,M11.1.0/2
admin@RT-AX86U_Pro:/tmp/home/root# ls -l /etc/localtime
lrwxrwxrwx 1 admin root 34 Nov 21 11:57 /etc/localtime -> /rom/usr/share/zoneinfo/US/Central
admin@RT-AX86U_Pro:/tmp/home/root# date
Sun Feb 23 18:11:46 CST 2025
I have the same router with the same issue and similar output.
 
When using AMTM it lists the date and UTC. The UTC is showing local time and not UTC. Where I'm at UTC is -6. Should the time show as local or UTC?
The output is correct. It should be showing your local time.

The suffix is merely the way unix indicates whether daylight saving is currently in effect. So the suffix (for your timezone) will either be UTC or DST.
 
The output is correct. It should be showing your local time.

The suffix is merely the way unix indicates whether daylight saving is currently in effect. So the suffix (for your timezone) will either be UTC or DST.
I feel like there’s a discrepancy though because a date without the TZ hint displays Central Standard Time correctly. The phony UTC6DST timezone seems to have a troubled history in Asus firmware.

There must be a reason @thelonelycoder adds a TZ hint to the date command, but it looks like the router would do the right thing without it in this particular case.
 
There must be a reason
IDK. By default $TZ doesn't exist and shell commands like date ignore /etc/TZ. So $TZ has to be set by some user script for the benefit of Entware , etc.

It's not really something I can check as I'm in GMT0 and there's currently no DST in effect. But I suspect it's to do with correctly reporting DST time.
 
By default $TZ doesn't exist and shell commands like date ignore /etc/TZ. So $TZ has to be set by some user script for the benefit of Entware , etc.
/bin/date will properly read /etc/localtime and /opt/bin/date (coreutils-date from Entware) will read /opt/etc/localtime which is a link to /etc/localtime.

amtm installs coreutils-date with the LED control script, so as long as the firmware is linking /etc/localtime to the correct timezone file, the TZ variable should be unnecessary.
Code:
rtradmin@router:/tmp/home/root# strace -E TZ=UTC6DST /bin/date
execve("/bin/date", ["/bin/date"], 0x28d60680 /* 20 vars */ <unfinished ...>
[ Process PID=28487 runs in 32 bit mode. ]
strace: WARNING: Proper structure decoding for this personality is not supported, please consider building strace with mpers support enabled.
<... execve resumed>)                   = 0
brk(NULL)                               = 0xd76000
uname({sysname="Linux", nodename="router", ...}) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, 0xffcf4618)                  = 0
mmap2(NULL, 14400, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7838000
close(3)                                = 0
openat(AT_FDCWD, "/lib/libcrypt.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\260\10\0\0004\0\0\0"..., 512) = 512
fstat64(3, 0xffcf4650)                  = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7836000
mmap2(NULL, 254312, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf77cd000
mprotect(0xf77d4000, 61440, PROT_NONE)  = 0
mmap2(0xf77e3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0xf77e3000
mmap2(0xf77e5000, 156008, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf77e5000
close(3)                                = 0
openat(AT_FDCWD, "/lib/libm.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0 s\0\0004\0\0\0"..., 512) = 512
fstat64(3, 0xffcf4640)                  = 0
mmap2(NULL, 663672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf772a000
mprotect(0xf77bb000, 65536, PROT_NONE)  = 0
mmap2(0xf77cb000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x91000) = 0xf77cb000
close(3)                                = 0
openat(AT_FDCWD, "/lib/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\220\366\0\0004\0\0\0"..., 512) = 512
fstat64(3, 0xffcf4630)                  = 0
mmap2(NULL, 192936, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf76fa000
mprotect(0xf7719000, 61440, PROT_NONE)  = 0
mmap2(0xf7728000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e000) = 0xf7728000
close(3)                                = 0
openat(AT_FDCWD, "/lib/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\\z\1\0004\0\0\0"..., 512) = 512
fstat64(3, 0xffcf4620)                  = 0
mmap2(NULL, 1323700, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf75b6000
mprotect(0xf76e4000, 65536, PROT_NONE)  = 0
mmap2(0xf76f4000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12e000) = 0xf76f4000
mmap2(0xf76f7000, 8884, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf76f7000
close(3)                                = 0
set_tls(0xf78376e0)                     = 0
mprotect(0xf76f4000, 8192, PROT_READ)   = 0
mprotect(0xf7728000, 4096, PROT_READ)   = 0
mprotect(0xf77cb000, 4096, PROT_READ)   = 0
mprotect(0xf77e3000, 4096, PROT_READ)   = 0
mprotect(0xa0000, 4096, PROT_READ)      = 0
mprotect(0xf783c000, 4096, PROT_READ)   = 0
munmap(0xf7838000, 14400)               = 0
getuid32()                              = 0
gettimeofday({tv_sec=2332787457468190, tv_usec=1481746537250818}, NULL) = 0
brk(NULL)                               = 0xd76000
brk(0xd97000)                           = 0xd97000
openat(AT_FDCWD, "/usr/share/zoneinfo/UTC6DST", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/zoneinfo/posixrules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
fstat64(1, 0xffcf4ee0)                  = 0
write(1, "Mon Feb 24 20:12:46 UTC 2025\n", 29Mon Feb 24 20:12:46 UTC 2025
) = 29
exit_group(0)                           = ?
+++ exited with 0 +++

rtradmin@router:/tmp/home/root# strace  /bin/date
execve("/bin/date", ["/bin/date"], 0x7fcb869660 /* 19 vars */ <unfinished ...>
[ Process PID=28774 runs in 32 bit mode. ]
strace: WARNING: Proper structure decoding for this personality is not supported, please consider building strace with mpers support enabled.
<... execve resumed>)                   = 0
brk(NULL)                               = 0x825000
uname({sysname="Linux", nodename="router", ...}) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, 0xff85fb58)                  = 0
mmap2(NULL, 14400, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf782c000
close(3)                                = 0
openat(AT_FDCWD, "/lib/libcrypt.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\260\10\0\0004\0\0\0"..., 512) = 512
fstat64(3, 0xff85fb90)                  = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf782a000
mmap2(NULL, 254312, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf77c1000
mprotect(0xf77c8000, 61440, PROT_NONE)  = 0
mmap2(0xf77d7000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0xf77d7000
mmap2(0xf77d9000, 156008, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf77d9000
close(3)                                = 0
openat(AT_FDCWD, "/lib/libm.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0 s\0\0004\0\0\0"..., 512) = 512
fstat64(3, 0xff85fb80)                  = 0
mmap2(NULL, 663672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf771e000
mprotect(0xf77af000, 65536, PROT_NONE)  = 0
mmap2(0xf77bf000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x91000) = 0xf77bf000
close(3)                                = 0
openat(AT_FDCWD, "/lib/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\220\366\0\0004\0\0\0"..., 512) = 512
fstat64(3, 0xff85fb70)                  = 0
mmap2(NULL, 192936, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf76ee000
mprotect(0xf770d000, 61440, PROT_NONE)  = 0
mmap2(0xf771c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e000) = 0xf771c000
close(3)                                = 0
openat(AT_FDCWD, "/lib/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\\z\1\0004\0\0\0"..., 512) = 512
fstat64(3, 0xff85fb60)                  = 0
mmap2(NULL, 1323700, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf75aa000
mprotect(0xf76d8000, 65536, PROT_NONE)  = 0
mmap2(0xf76e8000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12e000) = 0xf76e8000
mmap2(0xf76eb000, 8884, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf76eb000
close(3)                                = 0
set_tls(0xf782b6e0)                     = 0
mprotect(0xf76e8000, 8192, PROT_READ)   = 0
mprotect(0xf771c000, 4096, PROT_READ)   = 0
mprotect(0xf77bf000, 4096, PROT_READ)   = 0
mprotect(0xf77d7000, 4096, PROT_READ)   = 0
mprotect(0xa0000, 4096, PROT_READ)      = 0
mprotect(0xf7830000, 4096, PROT_READ)   = 0
munmap(0xf782c000, 14400)               = 0
getuid32()                              = 0
gettimeofday({tv_sec=1405379464210351, tv_usec=1481746537250818}, NULL) = 0
brk(NULL)                               = 0x825000
brk(0x846000)                           = 0x846000
openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, 0xff860418)                  = 0
fstat64(3, 0xff8602f0)                  = 0
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., 1024) = 1024
_llseek(3, 243, [1267], SEEK_CUR)       = 0
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 1024) = 1024
read(3, "\25I)\360\0\0\0\0\269\f\340\0\0\0\0\27)\v\360\0\0\0\0\30\")`\0\0\0\0"..., 1024) = 1024
read(3, "\1\2\1\2\1\2\1\2\1\2\1\2\1\2\1\2\1\2\1\2\1\2\1\2\1\2\1\2\1\2\1\2"..., 1024) = 204
close(3)                                = 0
fstat64(1, 0xff860420)                  = 0
write(1, "Mon Feb 24 21:15:11 EST 2025\n", 29Mon Feb 24 21:15:11 EST 2025
) = 29
exit_group(0)                           = ?
+++ exited with 0 +++
 
There must be a reason @thelonelycoder adds a TZ hint to the date command, but it looks like the router would do the right thing without it in this particular case.

That is what I'm seeing:
Code:
admin@RT-AX86U_Pro:/tmp/home/root# date
Mon Feb 24 20:21:20 CST 2025
admin@RT-AX86U_Pro:/tmp/home/root# TZ=$(nvram get time_zone_x) date
Mon Feb 24 20:21:39 UTC 2025
 
/bin/date will properly read /etc/localtime and /opt/bin/date (coreutils-date from Entware) will read /opt/etc/localtime which is a link to /etc/localtime.

amtm installs coreutils-date with the LED control script, so as long as the firmware is linking /etc/localtime to the correct timezone file, the TZ variable should be unnecessary.
You're right... and it reminded me that I had exactly the same conversation with the thelonelycoder back in 2022.

Without TZ being set the date command was saying I was in Ireland (IST) which I'm not - because that's what Asus linked /etc/localtime to :rolleyes: . It was me that persuaded him to add the TZ variable to his disk check script so that it correctly (for me) reported the DST abbreviation.

So you can blame me.

FYI below is the demonstration from back then:
Rich (BB code):
# echo $TZ
GMT0DST,M3.5.0/1,M10.5.0/2
# date
Wed Jun 29 20:14:59 DST 2022

# unset TZ
# date
Wed Jun 29 20:15:10 IST 2022


# ls -l /etc/localtime
lrwxrwxrwx    1 admin    root            37 Jun 29 15:16 /etc/localtime -> /rom/usr/share/zoneinfo/Europe/Dublin
# strings /rom/usr/share/zoneinfo/Europe/Dublin
TZif2
TZif2
GMT0IST,M3.5.0/1,M10.5.0

# rm /etc/localtime
# date
Wed Jun 29 19:15:56 UTC 2022

# ln -s /rom/usr/share/zoneinfo/Europe/London /etc/localtime
# date
Wed Jun 29 20:28:37 BST 2022

EDIT: We were aware that this was an imperfect solution but it was felt that displaying generic terms like GMT/UTC/DST was better than reporting incorrect country abbreviations. The later would always be wrong for some people all the while the Asus webUI groups different countries into a single time zone setting.
 
Last edited:
The output is correct. It should be showing your local time.

The suffix is merely the way unix indicates whether daylight saving is currently in effect. So the suffix (for your timezone) will either be UTC or DST.
Thanks for the explanation. In a previous life UTC/ZULU/GMT meant something. I've seen screenshots posted of users who had EST. My fault for bringing it up. It's not a big deal at all. I know what time it is. :)
 
Hi!

Been a few weeks/months since I can't update AMTM, didn't want to bother here but now I wonder that something must be wrong on my side.

Here's the output when I try to update:

AMTM.jpg


Any suggestions I may try?
Thanks in advance!
 
Hi!

Been a few weeks/months since I can't update AMTM, didn't want to bother here but now I wonder that something must be wrong on my side.

Here's the output when I try to update:

View attachment 64242

Any suggestions I may try?
Thanks in advance!
You're trying to update through China. Perhaps something is getting blocked going that route?
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top