What's new

amtm amtm 4.9 - the Asuswrt-Merlin Terminal Menu, June 30, 2024 (locked thread)

  • 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!

Attachments

  • 截屏图片 (1).jpg
    截屏图片 (1).jpg
    224.7 KB · Views: 45
  • 截屏图片.jpg
    截屏图片.jpg
    306.7 KB · Views: 44
What firmware do you have? Are you actually trying to install amtm when firmware versions since 384.15 have amtm already installed?
*EDIT* I see GT-AX6000
 
What firmware do you have? Are you actually trying to install amtm when firmware versions since 384.15 have amtm already installed?
*EDIT* I see GT-AX6000
388.4,installation succeeded via mobile hotspot, and perhaps it was indeed a network issue. Additionally, has “USB Disk Check at Boot “”been replaced by “Disk check script”? It seems to not be working now. I recall that during the initial installation, there was a prompt to install a script on the partition of the USB flash drive, but now it no longer asks. The USB flash drive also fails to be automatically mounted when the router is rebooted.
 
Well that is clear. This site is blocked somewhere.

Great it finally worked via a mobile (different ISP) connection.
 
Well that is clear. This site is blocked somewhere.

Great it finally worked via a mobile (different ISP) connection.
Well that is clear. This site is blocked somewhere.

Great it finally worked via a mobile (different ISP) connection.
However, this seems to be ineffective. "amtm" seems to be bound to a specific IP address, such as 192.168.43.17. After I install "amtm" by connecting to the router via mobile hotspot, when I switch to connecting to the router via LAN, the IP address changes to 192.168.50.1, and "amtm" becomes inactive, requiring a reinstallation.
I think the best approach is to save all the "amtm" folders and files to GitHub, where everyone can manually download the files. Additionally, GitHub can be accessed using accelerators to effectively bypass GFW restrictions.
 
"amtm" seems to be bound to a specific IP address, such as 192.168.43.17. After I install "amtm" by connecting to the router via mobile hotspot, when I switch to connecting to the router via LAN, the IP address changes to 192.168.50.1, and "amtm" becomes inactive, requiring a reinstallation.
I don't think so as it exists only on the router IP and I've never seen the IP change as you describe. Something seems unstable in your setup.
 
I don't think so as it exists only on the router IP and I've never seen the IP change as you describe. Something seems unstable in your setup.
You can try it, and it should be the same as me. Moving the hotspot and WAN will give the router different IP addresses for the LAN
 
However, this seems to be ineffective. "amtm" seems to be bound to a specific IP address, such as 192.168.43.17. After I install "amtm" by connecting to the router via mobile hotspot, when I switch to connecting to the router via LAN, the IP address changes to 192.168.50.1, and "amtm" becomes inactive, requiring a reinstallation.
I think the best approach is to save all the "amtm" folders and files to GitHub, where everyone can manually download the files. Additionally, GitHub can be accessed using accelerators to effectively bypass GFW restrictions.

Dude its pretty clear you've got GFW problems on what you call your "LAN" connection (do you really mean a wired-WAN connection? or are you doing double-NAT via an actual LAN? That might not be helping your situation if so) . As for the source files... well they are available... so if you can't figure that out, then you're over your head, and accessing the raw source files isn't going to help you'll just probably come here with even more problems. AND, if you got the full AMTM install to complete over the mobile hotspot then having raw files isn't going to help you at all... Bottom line you got other problems, amtm works fine for thousands of others...
 
I think the best approach is to save all the "amtm" folders and files to GitHub, where everyone can manually download the files. Additionally, GitHub can be accessed using accelerators to effectively bypass GFW restrictions.
Everything amtm is on my GitHub repo. But this is just for exposure and accountability. amtm pulls and deletes all files from my private server. No use to download files manually, it will not work.
 
Everything amtm is on my GitHub repo. But this is just for exposure and accountability. amtm pulls and deletes all files from my private server. No use to download files manually, it will not work.
If the IP address is not restricted, i can install and then connect to LAN after setting up a mobile hotspot, because the addresses of the mobile hotspot and LAN are definitely different. Currently, only the mobile hotspot is not affected by the Great Firewall (GFW).
 
Last edited:
Everything amtm is on my GitHub repo. But this is just for exposure and accountability. amtm pulls and deletes all files from my private server. No use to download files manually, it will not work.
It seems that it's not just about binding the IP address. I tried to modify the IP address of the LAN to be the same as the IP address of the mobile hotspot, but amtm still cannot be used. Why?
 
You're operating in out of the norm ways. Virtually no-one has connected this way, and for this reason, so virtually no-one can help - without wiping their router and setting it up to replicate your setup.
Safe to say, any advice given for your "issue" will just be suggestions on things to try.
 
It seems that it's not just about binding the IP address. I tried to modify the IP address of the LAN to be the same as the IP address of the mobile hotspot, but amtm still cannot be used. Why?

Sorry man. But you are just proving everything you've been told over and over - that its the GFW on your "LAN" connection dude.
I always knew that the IP address thing was a silly theory.
Obviously your mobile hotspot has different filtering/blocking than your wired broadband.

Again. You are just confirming everything everyone has told you here.
It is blocks on your "LAN" broadband (WAN really but you seem committed to using the wrong terms).
Your only hope would be maybe if you can open a VPN for the router, but I know from my time in PRC that can also be a PITA since they got wise to blocking VPN's like 15yrs ago so its like whack a mole... you can get one to work for a while then they'll block it and you need to try another etc. etc. etc.
 
Sorry man. But you are just proving everything you've been told over and over - that its the GFW on your "LAN" connection dude.
I always knew that the IP address thing was a silly theory.
Obviously your mobile hotspot has different filtering/blocking than your wired broadband.

Again. You are just confirming everything everyone has told you here.
It is blocks on your "LAN" broadband (WAN really but you seem committed to using the wrong terms).
Your only hope would be maybe if you can open a VPN for the router, but I know from my time in PRC that can also be a PITA since they got wise to blocking VPN's like 15yrs ago so its like whack a mole... you can get one to work for a while then they'll block it and you need to try another etc. etc. etc.
I accidentally found that the reason for the failure of the mobile hotspot amtm to reconnect to the LAN was that the "USB2JFFS" I installed used the SD1 partition. Now that I formatted SD1, the amtm installed under the mobile hotspot can be used. The IP address is indeed a stupid theory.
 
I dont think script update notiification option 1. send a test notification email is working - Is it working for anybody?
 
I dont think script update notiification option 1. send a test notification email is working - Is it working for anybody?
Strangely enough I've not had a Script Update notification since May 16 (supposed to be weekly on Sunday), though the Testmail option (both option 1 and 2)works fine.
 
Last edited:
Strangely enough I've not had a Script Update notification since May 16 (supposed to be weekly on Sunday), though the Testmail option (both option 1 and 2)works fine.
It has been working for me both on an AC1900P and a AX86S.
 
Since the update of amtm to 4.8 the behaviour of led control seems to have changed. When manually set to "off" the setting no longer survives a reboot. The LEDs are on after a reboot and led control is set back to "on".
I only mention this now as I thought a factory reset and manual rebuild could fix it - it hasn't.
 
Since the update of amtm to 4.8 the behaviour of led control seems to have changed. When manually set to "off" the setting no longer survives a reboot. The LEDs are on after a reboot and led control is set back to "on".
I only mention this now as I thought a factory reset and manual rebuild could fix it - it hasn't.
See the explanatory text when opening lc:
Manually setting the LEDs is preserved
between reboots, same as the WebUI setting.
However, the LED scheduler has precedence
over the manual setting.
 

Similar threads

Latest threads

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!
Top