amtm amtm - the Asuswrt-Merlin Terminal Menu

[Jack Yaz]

I need a break from coding. T'was a good excuse to stop my feature creep tendency.

I hear ya!

 

[WuTang LAN]

No point in burning yourselves out, @thelonelycoder & @Jack Yaz.

 

[QuikSilver]

No point in burning yourselves out, @thelonelycoder & @Jack Yaz.

I agree! Don't let your hobby turn into something you can't enjoy.

 

[heysoundude]

I haven't gotten around to installing entware/diversion on my ac86 (used to have it on my n66...big upgrade), but I have a question:
this appears such that I can install amtm in scripts, use it to format a USB drive and run a swap BEFORE getting entware etc happening - is that correct?

 

[L&LD]

I haven't gotten around to installing entware/diversion on my ac86 (used to have it on my n66...big upgrade), but I have a question:
this appears such that I can install amtm in scripts, use it to format a USB drive and run a swap BEFORE getting entware etc happening - is that correct?

amtm Step-by-Step https://www.snbforums.com/threads/amtm-step-by-step-install-guide-l-ld.56237/#post-483421

Yes!

 

[heysoundude]

Excelsior!


Sent from my iPhone using Tapatalk

 

[thelonelycoder]

I haven't gotten around to installing entware/diversion on my ac86 (used to have it on my n66...big upgrade), but I have a question:
this appears such that I can install amtm in scripts, use it to format a USB drive and run a swap BEFORE getting entware etc happening - is that correct?

Yup, in that order.

 

[heysoundude]

I’ll try to find some time this weekend to get on that. Thank you.


UPDATE: updated Merlin to 384.11_2, added amtm, created swap...and am I ever glad I did! Thanks @RMerlin and @thelonelycoder !!

 

[Elmer]

thelonelycoder said: ↑
I need a break from coding. T'was a good excuse to stop my feature creep tendency.

Just wanted to chime in and tell you how much I appreciate amtm. Before you came along, I would install a script, probably mess it up, never update, and finally just reformat jffs since I blamed the scripts for whatever the days router problems were. I'm now properly running four scripts, including diversion, which is a godsend. You've made Asus routers and Merlin firmware a step above for all of us that are uncomfortable with ssh, scripts and, well programming. Thanks, and please ignore the bitching about themes.

 

[thelonelycoder]

Before you came along, I would install a script, probably mess it up, never update, and finally just reformat jffs since I blamed the scripts for whatever the days router problems were.

I remember spending my time doing something else (on the computer). Then I had an idea and in the process of it stumbled upon this forum and found Asuswrt-Merlin. That was sometime in January 2014. My live has been transformed since.

Thanks, and please ignore the bitching about themes.

I'm good, thanks. They're nice, aren't they?

 

[thelonelycoder]

Apologies in advance ... I'm sure you are kept busy enough without me chiming in ... but here comes another "non-coder" feature request: -

Relates to my post under fw 384.12-alpha1 here ... https://www.snbforums.com/threads/384-12_alpha-builds-testing-all-variants.56639/page-6#post-492419 ... but not sure that firmware change is feasible.

I then discovered this post [dealing with another issue - but with ntp sync at the heart of the problem] https://www.snbforums.com/threads/t...ugged-on-rt-ax88u-11.56524/page-2#post-492172

So ... I thought perhaps the solution for your amtm / disk check ... and its many add-on scripts - was to build in a short delay - [10 to 20 seconds?] -before any of the amtm provided scripts execute - so that the WAN is up and ntp is in sync first?

Not only would this give an accurate time stamp for Disk Check log - but also possibly resolve some of the other issues which arise for lack of ntp sync?

I did reject your request in the Diversion thread. Here, in the amtm thread, I realized that your proposal is advantageous for the disk check script and others.

May 22 19:37:48 amtm disk-check: Waited 2 seconds for NTP to sync date
May 22 19:37:48 amtm disk-check: Probing ext4 on device /dev/sdb1
May 22 19:37:48 amtm disk-check: Running disk check (v2.2) 'e2fsck -p' on /dev/sdb1
May 22 19:37:48 amtm disk-check: Disk check done on /dev/sdb1

The timeout for NPT to sync is 30 seconds, then it will run anyway.
Coming to a router near you with the next amtm update.

 

[kernol]

I did reject your request in the Diversion thread. Here, in the amtm thread, I realized that your proposal is advantageous for the disk check script and others.

May 22 19:37:48 amtm disk-check: Waited 2 seconds for NTP to sync date
May 22 19:37:48 amtm disk-check: Probing ext4 on device /dev/sdb1
May 22 19:37:48 amtm disk-check: Running disk check (v2.2) 'e2fsck -p' on /dev/sdb1
May 22 19:37:48 amtm disk-check: Disk check done on /dev/sdb1

The timeout for NPT to sync is 30 seconds, then it will run anyway.
Coming to a router near you with the next amtm update.

Thanks for that {thumbs-Up} ... it will fix the time stamp for disk-check - but I remain convinced that, through your control of what is approved for inclusion in the amtm menu system, a collaborative effort can be achieved for all coder participants to have the /jffs/script execution delayed for that 30 second period to get time synced before they execute.

In the syslog extract I quoted in the "rejected" post it is clear that "firewall-start" kicks off first well before any time sync has occurred. That kicks off skynet and yazfi - leaving them looping around "lock file" issues until time is in sync when they can execute properly. There are several other instances of these /jffs/scripts firing up without time in sync [can't see the point of this?].

I also wonder whether the process has to wait a full 30 seconds - could an internment test not run to check time sync - and as soon as sync occurs ... proceed with script execution. The ntp delay test should exit anyway when 30 seconds have elapsed and no confirmation of time sync is received?

EDIT : ntpstat command?

 

[Jack Yaz]

Thanks for that {thumbs-Up} ... it will fix the time stamp for disk-check - but I remain convinced that, through your control of what is approved for inclusion in the amtm menu system, a collaborative effort can be achieved for all coder participants to have the /jffs/script execution delayed for that 30 second period to get time synced before they execute.

In the syslog extract I quoted in the "rejected" post it is clear that "firewall-start" kicks off first well before any time sync has occurred. That kicks off skynet and yazfi - leaving them looping around "lock file" issues until time is in sync when they can execute properly. There are several other instances of these /jffs/scripts firing up without time in sync [can't see the point of this?].

I also wonder whether the process has to wait a full 30 seconds - could an internment test not run to check time sync - and as soon as sync occurs ... proceed with script execution. The ntp delay test should exit anyway when 30 seconds have elapsed and no confirmation of time sync is received?

EDIT : ntpstat command?

YazFi doesn't need NTP - the lock files are where the firewall is restarted multiple times during the system boot

 

[thelonelycoder]

I also wonder whether the process has to wait a full 30 seconds - could an internment test not run to check time sync - and as soon as sync occurs ... proceed with script execution. The ntp delay test should exit anyway when 30 seconds have elapsed and no confirmation of time sync is received?

30s is the timeout to run it anyway, else it runs whenever NTP is synced.

ntptimer=0
ntptimeout=30
while [ "$(nvram get ntp_ready)" = "0" ] && [ "$ntptimer" -lt "$ntptimeout" ]; do
    ntptimer=$((ntptimer+1))
    sleep 1
done

Description what code does for non-coders: It just works, believe me.
Thanks @Adamm , blatantly lifted off of Skynet.

 

[cmkelley]

Thanks for that {thumbs-Up} ... it will fix the time stamp for disk-check - but I remain convinced that, through your control of what is approved for inclusion in the amtm menu system, a collaborative effort can be achieved for all coder participants to have the /jffs/script execution delayed for that 30 second period to get time synced before they execute.

I would be very much against an across the board approach that would impact everyone. If your system needs time as quickly as possible, there are relatively easy ways to achieve this. The easiest is to set up a system as a time server (with a static IP) and put a loop in init-start to continuously query the IP of that system until the LAN comes up, then get the time and set ntp_ready. I have a raspberry pi I use for a time server (it gets GPS time), and it gets time within 2 seconds of being started. I'm pretty sure the LAN comes up before the WAN, and certainly before DNS, so using a time server internal to your network is the very fastest way to get time. I'll put a script up in Gist of what I use.

 

[cmkelley]

Thanks for that {thumbs-Up} ... it will fix the time stamp for disk-check - but I remain convinced that, through your control of what is approved for inclusion in the amtm menu system, a collaborative effort can be achieved for all coder participants to have the /jffs/script execution delayed for that 30 second period to get time synced before they execute.

See my Gist at: https://gist.github.com/cynicastic/ced78fac27de4394b67977802d76c0d9 - put it in /jffs/scripts, make it executable, and call from init-start with

/jffs/scripts/fetch-ntp ww.xx.yy.zz cc &

Where 'ww.xx.yy.zz' is the IP of your LAN ntp server. Don't use a hostname, and certainly don't use an external time server if you're going to take this approach. 'cc' is optional, the number of seconds you want it to keep trying. As I said, using the IP address of my LAN time server, I get the time within 2 seconds of the script starting, and consistently immediately after nat and dropbear start.

May  4 22:05:06 nat: apply redirect rules
May  4 22:05:06 dropbear[776]: Running in background
May  8 19:59:48 SCRIPT_fetch-ntp: Time synced (Wed May  8 19:59:48 DST 2019) from W.X.Y.Z in 2 cycles

For reference, the first timestamp in the startup log is May 4 22:05:05, so this happens very early in the boot process. I just looked and it gets the time from my ntp server 12 seconds before the USB drive is mounted, and the WAN comes up right after the USB drive is mounted.

If you're concerned about stuff having the right time, pointing your router at a local ntp server is the best bet.

 

[thelonelycoder]

So will the script be applicable if the Router is the ntp server?

Hmmm.

 

[joe scian]

Hmmm.

I guess its good for a message to the log !!

 

[kernol]

I would be very much against an across the board approach that would impact everyone. If your system needs time as quickly as possible, there are relatively easy ways to achieve this. The easiest is to set up a system as a time server (with a static IP) and put a loop in init-start to continuously query the IP of that system until the LAN comes up, then get the time and set ntp_ready. I have a raspberry pi I use for a time server (it gets GPS time), and it gets time within 2 seconds of being started. I'm pretty sure the LAN comes up before the WAN, and certainly before DNS, so using a time server internal to your network is the very fastest way to get time. I'll put a script up in Gist of what I use.

Agreed - which is why the solution rests with amtm and any of its scripts which either require time to be synced or which log meaningful activities for record purposes [like disk-check].

 

[thelonelycoder]

I guess its good for a message to the log !!

Some have elaborate setups with GPS receivers attached to the router to get (more) accurate time.
Looks like some people have hobbies that involve spending exessive time with with routers. Imagine that!