amtm amtm - the Asuswrt-Merlin Terminal Menu

[thelonelycoder]

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].

Since the future disk check includes the wait code for NTP to be up, other scripts just could wait until the disks are mounted. Or use a check themselves.

I don't wont to harass the amtm-included-script coders more than necessary just for my personal and technical requirements to be included in amtm.

 

[kernol]

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.

Excellent solution - provided you are running an internal [local] ntp service.
I have a Synology NAS box which I could use - but then would have to change its config ... which is set to "sleep" after a period of inactivity - and it takes a while to wake up following a request on the LAN.

Just curious - if I created an init-start script and placed the code @thelonelycoder lifted from @Adamm with thanks - restated below ...

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

Would that cause problems ... or could it work before other /jffs/scripts are executed?

 

[kernol]

Since the future disk check includes the wait code for NTP to be up, other scripts just could wait until the disks are mounted. Or use a check themselves.

I don't wont to harass the amtm-included-script coders more than necessary just for my personal and technical requirements to be included in amtm.

Fully understood - I just hope that the other coders take heed of the time sync issues where it may be needed for their add-ons - especially now with Melrin firmware including ntpd functionality - which at present seems to be started and stopped several times by intervening /jffs/scripts [if I understand the logs correctly].

 

[thelonelycoder]

Excellent solution - provided you are running an internal [local] ntp service.
I have a Synology NAS box which I could use - but then would have to change its config ... which is set to "sleep" after a period of inactivity - and it takes a while to wake up following a request on the LAN.

Just curious - if I created an init-start script and placed the code @thelonelycoder lifted from @Adamm with thanks - restated below ...

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

Would that cause problems ... or could it work before other /jffs/scripts are executed?

If the while loop is above other scripts in that file, then yes, it will delay execution of them.

 

[cmkelley]

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].

Right, the solution rests with scripts that _require_ accurate timestamps to wait until ntp_ready is 1 and then continue. Most scripts don't actually care if the time is correct or not and there shouldn't be a block keeping them all from running just so a select few that need the correct time have it. It's up to the individual script writer to decide if the script needs accurate time or not.

 

[cmkelley]

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!

Actually my GPS receiver is hooked to my Raspberry Pi. My hobbies extend beyond the router.

 

[cmkelley]

Excellent solution - provided you are running an internal [local] ntp service.
I have a Synology NAS box which I could use - but then would have to change its config ... which is set to "sleep" after a period of inactivity - and it takes a while to wake up following a request on the LAN.

How often do you reboot your router when you haven't recently accessed your file server? And if "a while" is less than 5 seconds, that's very likely still noticeably less time than it will take for the router WAN and DNS to come up.

Almost any computer can be configured to be an ntp server. There's even an ntpd available for windows. The routers are rather unique in not having a battery or capacitor backed clock.

Just curious - if I created an init-start script and placed the code @thelonelycoder lifted from @Adamm with thanks - restated below ...

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

Would that cause problems ... or could it work before other /jffs/scripts are executed?

It wouldn't do any good. If init-start is blocking (I don't remember if it is) it would prevent the system from getting the time and would time out every time. If init-start isn't blocking, the only thing it will prevent from running are scripts that are called from init-start after that loop. Scripts started in post-mount, nat-start, wan-start, etc. would be unaffected by that loop, and time still might not get set before they are called.

 

[thelonelycoder]

Actually my GPS receiver is hooked to my Raspberry Pi. My hobbies extend beyond the router.

Oh? You unicorn, you!

 

[cmkelley]

Oh? You unicorn, you!

 

[Dabombber]

It wouldn't do any good. If init-start is blocking (I don't remember if it is) it would prevent the system from getting the time and would time out every time. If init-start isn't blocking, the only thing it will prevent from running are scripts that are called from init-start after that loop. Scripts started in post-mount, nat-start, wan-start, etc. would be unaffected by that loop, and time still might not get set before they are called.

Easy fix, just run it in a background subshell:

#!/bin/sh

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

    // Do stuff here
) &

 

[cmkelley]

Easy fix, just run it in a background subshell:

#!/bin/sh

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

    // Do stuff here
) &

That doesn't fix anything, it just makes the loop totally ineffectual. Scripts after it in init-start will run, as will all of the normal post-mount, nat-start, etc. scripts and anything that those call regardless of the status of the clock. It's just a loop running in the background doing nothing.

 

[Dabombber]

Obviously the "Do stuff here" would be replaced by whatever relies on ntp.

 

[cmkelley]

Obviously the "Do stuff here" would be replaced by whatever relies on ntp.

Ahhh, missed that note.

Still doesn't prevent scripts in post-mount, nat-start, etc from running without the system clock set though. If a script relies on ntp AND on say the USB drive being mounted, init-start is the wrong place to put it, it should go in post-mount with a check for ntp_ready.

 

[L&LD]

I am seeing an issue on my RT-AC86U running RMerlin 384.12 Alpha (latest) and when running the 'su' command in amtm 2.2 latest version (or using 'u' for amtm or for any of the supported scripts installed), takes about 2 minutes to finish checking for updates (about 15 to 20 seconds per script).

Whether Diversion is disabled or not and also tested after a reboot of the router too.

I am also using DoT in the 384.12 A1 firmware with 1.1.1.1 and 1.0.0.1 Cloudflare DNS servers including DNSFilter in 'router' default mode.

Is anyone else seeing this? Before I format the drive and re-install (which is no hardship) or try other random troubleshooting steps, I was just curious how I might be able to track this down

before then​

, if possible?

I'm only posting this here because there doesn't seem to be a 'best' thread to post this to.

I'm also not suggesting amtm is the issue, just where the symptoms are most noticeable.

I wouldn't be surprised if this was the end of the line for 'dirty' upgrades on this RT-AC86U, including many alphas and betas from 384.10_0.

This isn't a showstopper for me, but it is a little disconcerting (is the 256GB USD drive dying?). I am planning a full M&M Config + fresh amtm Step-by-Step install when 384.12 goes final. I could easily live with this issue until then.

Thanks for any suggestions.

 

[Butterfly Bones]

I am seeing an issue on my RT-AC86U running RMerlin 384.12 Alpha (latest) and when running the 'su' command in amtm 2.2 latest version (or using 'u' for amtm or for any of the supported scripts installed), takes about 2 minutes to finish checking for updates (about 15 to 20 seconds per script).

Whether Diversion is disabled or not and also tested after a reboot of the router too.

I am also using DoT in the 384.12 A1 firmware with 1.1.1.1 and 1.0.0.1 Cloudflare DNS servers including DNSFilter in 'router' default mode.

Is anyone else seeing this? Before I format the drive and re-install (which is no hardship) or try other random troubleshooting steps, I was just curious how I might be able to track this down

before then​

, if possible?

I'm only posting this here because there doesn't seem to be a 'best' thread to post this to.

I'm also not suggesting amtm is the issue, just where the symptoms are most noticeable.

I wouldn't be surprised if this was the end of the line for 'dirty' upgrades on this RT-AC86U, including many alphas and betas from 384.10_0.

This isn't a showstopper for me, but it is a little disconcerting (is the 256GB USD drive dying?). I am planning a full M&M Config + fresh amtm Step-by-Step install when 384.12 goes final. I could easily live with this issue until then.

Thanks for any suggestions.

No, almost same RMerlin firmware, DoT settings / servers. I have however removed almost all scripts (see sig) after a power outage F!U!B!A!R! yesterday as they do a rehab on the housing complex where I live. After eight hours of no power / Internet I'm still rebuilding...

 

[dave14305]

I am seeing an issue on my RT-AC86U running RMerlin 384.12 Alpha (latest) and when running the 'su' command in amtm 2.2 latest version (or using 'u' for amtm or for any of the supported scripts installed), takes about 2 minutes to finish checking for updates (about 15 to 20 seconds per script).

Whether Diversion is disabled or not and also tested after a reboot of the router too.

I am also using DoT in the 384.12 A1 firmware with 1.1.1.1 and 1.0.0.1 Cloudflare DNS servers including DNSFilter in 'router' default mode.

Is anyone else seeing this? Before I format the drive and re-install (which is no hardship) or try other random troubleshooting steps, I was just curious how I might be able to track this down

before then​

, if possible?

I'm only posting this here because there doesn't seem to be a 'best' thread to post this to.

I'm also not suggesting amtm is the issue, just where the symptoms are most noticeable.

I wouldn't be surprised if this was the end of the line for 'dirty' upgrades on this RT-AC86U, including many alphas and betas from 384.10_0.

This isn't a showstopper for me, but it is a little disconcerting (is the 256GB USD drive dying?). I am planning a full M&M Config + fresh amtm Step-by-Step install when 384.12 goes final. I could easily live with this issue until then.

Thanks for any suggestions.

How long does it take your router via ssh to run:

nslookup raw.githubusercontent.com

If it’s not instantaneous, what is in /etc/resolv.conf?

 

[Marin]

I am seeing an issue on my RT-AC86U running RMerlin 384.12 Alpha (latest) and when running the 'su' command in amtm 2.2 latest version (or using 'u' for amtm or for any of the supported scripts installed), takes about 2 minutes to finish checking for updates (about 15 to 20 seconds per script).

Whether Diversion is disabled or not and also tested after a reboot of the router too.

I am also using DoT in the 384.12 A1 firmware with 1.1.1.1 and 1.0.0.1 Cloudflare DNS servers including DNSFilter in 'router' default mode.

Is anyone else seeing this? Before I format the drive and re-install (which is no hardship) or try other random troubleshooting steps, I was just curious how I might be able to track this down

before then​

, if possible?

I'm only posting this here because there doesn't seem to be a 'best' thread to post this to.

I'm also not suggesting amtm is the issue, just where the symptoms are most noticeable.

I wouldn't be surprised if this was the end of the line for 'dirty' upgrades on this RT-AC86U, including many alphas and betas from 384.10_0.

This isn't a showstopper for me, but it is a little disconcerting (is the 256GB USD drive dying?). I am planning a full M&M Config + fresh amtm Step-by-Step install when 384.12 goes final. I could easily live with this issue until then.

Thanks for any suggestions.

Same here for the AMTM issue. The entire menu loads up very slowly and when typing “su”. I thought it was my USB stick slowly dying this AM but thought of leaving it there for now. Tried it this afternoon and the same thing is still happening.


Sent from my iPhone using Tapatalk

 

[thelonelycoder]

Same here for the AMTM issue. The entire menu loads up very slowly and when typing “su”. I thought it was my USB stick slowly dying this AM but thought of leaving it there for now. Tried it this afternoon and the same thing is still happening.

No issues here, must be some network delay at GitHub or slow resolving of https://raw.githubusercontent.com. If the Diversion check is done almost instantly while the others take (much) longer, then, well, someone else will figure out who's s throttling progress.

Anyway: Next up, see ↓↓↓ below

 

[thelonelycoder]

amtm 2.3 is now available

What's new in amtm 2.3
- Bug fixes and code improvements
- Basic Swap partition support added, supporting fstab or post-mount entry
- Improved logic for regular swap file detection and (auto) management
- Disk check version 2.3: Added NTP timer (with timeout), disk check log now shows correct time stamp
- Better disk check log format
Edit: - Swap file/partition size is now shown

How to update
Use u to update

 

[Clark Griswald]

That was simple enough!
I am not seeing any delays in amtm options for script update checks "su", nor in amtm "u"