amtm amtm v6.7.2 [2026-Apr-19] - the Asuswrt-Merlin Terminal Menu

[thelonelycoder]

Welcome, this is amtm 6.7.2, the Asuswrt-Merlin Terminal Menu

amtm is a front end that manages popular scripts for wireless routers running Asuswrt-Merlin firmware.
amtm is hosted on the Diversion website: https://diversion.ch/amtm.html

What's new in amtm

• Increases prerelease version check from 3 to 5 for AdGuardHome. Thanks to @SomeWhereOverTheRainBow for the pull request.
• Some minor formatting, transparency and code changes.

 

[visortgw]

@thelonelycoder: Can you please consider performing autoupdate when MD5 hash change is detected, but there is no version change for 3rd-party scripts (e.g., Skynet and RTRMON today)? Currently, updates must be initiated manually.

 

[thelonelycoder]

@thelonelycoder: Can you please consider performing autoupdate when MD5 hash change is detected, but there is no version change for 3rd-party scripts (e.g., Skynet and RTRMON today)? Currently, updates must be initiated manually.

MD5 hash changes can have multiple reasons, I am reluctant to allow auto-updates for these in amtm.

• I used to push updates for both amtm and Diversion with minor changes and NO version change. This happened for various and non-nefarious reasons.
  It got so bad that users complained that my update strategy is flawed - and they were right. So I changed it, see this post. I since follow strictly the most used versioning system, with the major.minor.patch numbering system for both amtm and Diversion.
• An MD5 hash change can also mean a compromised script file on your router or a hacked server file. This is not unheard of and the hash change might be an indicator for that. Another reason why I no longer push updates without a version change.
• And then there's the laziness of script writers - that used to include me! - to push an update and not inform users via a post or something. There may be more reasons, I am just to lazy to type more ...

Anyway, you may try to convince me otherwise.

 

[Mutzli]

@thelonelycoder: Can you please consider performing autoupdate when MD5 hash change is detected, but there is no version change for 3rd-party scripts (e.g., Skynet and RTRMON today)? Currently, updates must be initiated manually.

Skynet had a small update today:

fix IOT rule checks for proper param order by dave14305 · Pull Request #194 · Adamm00/IPSet_ASUS

Creates false integrity violations when iotports is populated. Actual output from 3006.102.7_2 iptables: -A FORWARD -i br+ -o eth0 -p tcp -m set --match-set Skynet-IOT src -m tcp -m multiport --dpo...

github.com

 

[visortgw]

MD5 hash changes can have multiple reasons, I am reluctant to allow auto-updates for these in amtm.

• I used to push updates for both amtm and Diversion with minor changes and NO version change. This happened for various and non-nefarious reasons.
  It got so bad that users complained that my update strategy is flawed - and they were right. So I changed it, see this post. I since follow strictly the most used versioning system, with the major.minor.patch numbering system for both amtm and Diversion.
• An MD5 hash change can also mean a compromised script file on your router or a hacked server file. This is not unheard of and the hash change might be an indicator for that. Another reason why I no longer push updates without a version change.
• And then there's the laziness of script writers - that used to include me! - to push an update and not inform users via a post or something. There may be more reasons, I am just to lazy to type more ...

Anyway, you may try to convince me otherwise.

Today's changes for both RTRMON and Skynet were both the third reason — yes, we need to discourage deployment of patches without version number change. Possibly a prompt to override when user knows it's a legit change?

 

[thelonelycoder]

Possibly a prompt to override when user knows it's a legit change?

I am not going to encourage bad behavior.

 

[visortgw]

I am not going to encourage bad behavior.

Fair enough...

 

[dave14305]

I am not going to encourage bad behavior.

What about just ignoring md5 hashes completely? No version change, no update. The older notion of a “hotfix” without a version bump is sloppy by today’s standards (IMO).

Today, Adamm merged a PR I sent. Should users be getting it immediately if Adamm didn’t also bump the version? Probably not. Skynet itself might consider it a hotfix, but for most users in this mature ecosystem, it’s probably not warranted anymore.

 

[thelonelycoder]

What about just ignoring md5 hashes completely? No version change, no update. The older notion of a “hotfix” without a version bump is sloppy by today’s standards (IMO).

Today, Adamm merged a PR I sent. Should users be getting it immediately if Adamm didn’t also bump the version? Probably not. Skynet itself might consider it a hotfix, but for most users in this mature ecosystem, it’s probably not warranted anymore.

As explained above, the hash change has its own merits. It tells users something has changed between the installed script and the server version. As I always say to my friends and coworkers: Use your head - by pointing at my head

Even hotfixes have version changes. Name one software product you use that releases an update without a version change.
By showing there is a hash change but not offering the amtmupdate elegance, I make a statement.

 

[Viktor Jaep]

@thelonelycoder: Can you please consider performing autoupdate when MD5 hash change is detected, but there is no version change for 3rd-party scripts (e.g., Skynet and RTRMON today)? Currently, updates must be initiated manually.

Full disclosure. I don't do this very often, but RTRMON showed an MD5 update today due to the fact that I moved a line of code from one line to another line in order for amtmupdate to function correctly. That's literally it. This was so extremely minor that it didn't warrant going through all the motions, github pushes, pulls, documentation, links etc. for a version change in my opinion.

 

[thelonelycoder]

Full disclosure. I don't do this very often, but RTRMON showed an MD5 update today due to the fact that I moved a line of code from one line to another line in order for amtmupdate to function correctly. That's literally it. This was so extremely minor that it warranted going through all the motions, github pushes, pulls, documentation, links etc. for a version change in my opinion.

You yourself pledged to also use the major.minor.patch pattern. Swapping a line to make a function do what it‘s supposed to do is called a patch.

 

[thelonelycoder]

And now that all this is out of the way, I hope to settle down with a Martini Fiero on ice on my balcony and enjoy the evening.

 

[dave14305]

I remember being one of the first (or only) script owner to use the # amtm NoMD5check to avoid amtm detecting md5 changes.

https://github.com/decoderman/amtm/blob/12d712e18176c0da7aa9e4ff62ecfe692caa79f2/amtm_modules/amtm.mod#L901

 

[thelonelycoder]

I remember being one of the first (or only) script owner to use the # amtm NoMD5check to avoid amtm detecting md5 changes.

https://github.com/decoderman/amtm/blob/12d712e18176c0da7aa9e4ff62ecfe692caa79f2/amtm_modules/amtm.mod#L901

That is still supported.

 

[Viktor Jaep]

You yourself pledged to also use the major.minor.patch pattern. Swapping a line to make a function do what it‘s supposed to do is called a patch.

Thanks for keeping me honest. I'll make sure to account for each version change no matter how minute it might be. Enjoy your beverage of choice!

 

[dave14305]

That is still supported.

But only used in FlexQoS.

https://github.com/search?q=%2F%5E%23+amtm+NoMD5check%2F&type=code

 

[SomeWhereOverTheRainBow]

Is this something that needs to be worked on by @SomeWhereOverTheRainBow (if he is still maintaining AMAGHI) or ... ??

There are 3 AGH prerelease versions since the last release, so the GitHub api fetch never sees the release version because the curl call limits the output to 3 versions. If it were 4, it would work fine.

My installer script does 5, amtm AGH module does 3. I just pushed a patch to match the installer script.

I figured 3 was enough at the time, and I wanted to keep it light and quick for @thelonelycoder script, but now i see the error of my ways. adding 2 more to the check should not cause too much delay. we are looking at miliseconds.
I am just waiting for @thelonelycoder seal of approval.

Update AdGuardHome.mod by jumpsmm7 · Pull Request #50 · decoderman/amtm

major fix to AMTM AdGuardHome Version check module

github.com

 

[thelonelycoder]

My installer script does 5, amtm AGH module does 3. I just pushed a patch to match the installer script.

I figured 3 was enough at the time, and I wanted to keep it light and quick for @thelonelycoder script, but now i see the error of my ways. adding 2 more to the check should not cause too much delay. we are looking at miliseconds.
I am just waiting for @thelonelycoder seal of approval.

Update AdGuardHome.mod by jumpsmm7 · Pull Request #50 · decoderman/amtm

major fix to AMTM AdGuardHome Version check module

github.com

Thanks, a simple fix for a major headache
I suppose with the complexity of the install/update procedure in AdGuardHome you won't be implementing the amtmupdate option into this script.
If so, I will not pester you to add support.

 

[thelonelycoder]

amtm 6.7.2 is now available

• Increases prerelease version check from 3 to 5 for AdGuardHome. Thanks to @SomeWhereOverTheRainBow for the pull request.
• Some minor formatting, transparency and code changes.