amtm amtm - the Asuswrt-Merlin Terminal Menu

[EeK]

I also only wanted to block ads on the router . About 5 years ago I found out about Asuswrt-Merlin.
Today I own 7 Asus routers and have spent countless hours on the scripts I freely give away on this board.
I'm sorry to hear your router appears to be bricked. That 87U is a special model and the one I have has a dead WAN port. But it's still good as a test unit for my scripts.

@thelonelycoder, I'm writing this in a separate reply, as you're the author of this thread and the creator of many of the scripts being discussed.

I didn't mean to imply that your script is what caused my router to stop working, and in the case my post led you to believe that, I apologize if the wording wasn't clearer. I appreciate your hard work and was just venting out my frustration after having a working and painstakingly configured device one second, and a paperweight the next.

I did mention in a previous comment that my router had already exhibited the same behavior, long before I dabbled with amtm and without any interference from my part. I still don't know what caused those issues to appear, in the first place. At the time, my modem had switched back from bridged to NAT (with my ISP's default settings), so I suspect it received a remote update from them. Not sure how that would affect my router, however.

As for the most recent occasion, I was trying different USB devices. The first one I tried (a SanDisk Ultra Fit) was showing up when connected to any of the two ports, but as "unmounted". The following two I tried (both SanDisk Cruzer - 64 and 256GB; both formated as NTFS; both working properly under Windows) didn't even show up. And after a reboot to try to fix that issue, the router went silent.

Is it possible that the USB devices short-circuited the device, somehow? Or was it just a coincidence that the router bricked/died at the exact same time?

 

[Asad Ali]

@thelonelycoder, I'm writing this in a separate reply, as you're the author of this thread and the creator of many of the scripts being discussed.

I didn't mean to imply that your script is what caused my router to stop working, and in the case my post led you to believe that, I apologize if the wording wasn't clearer. I appreciate your hard work and was just venting out my frustration after having a working and painstakingly configured device one second, and a paperweight the next.

I did mention in a previous comment that my router had already exhibited the same behavior, long before I dabbled with amtm and without any interference from my part. I still don't know what made those issues to appear, in the first place. At the time, my modem had switched back from bridged to NAT (with my ISP's default settings), so I suspect it received a remote update from them. Not sure how that would affect my modem, however.

As for the most recent occasion, I was trying different USB devices. The first one I tried (a SanDisk Ultra Fit) was showing up when connected to any of the two ports, but as "unmounted". The following two I tried (both SanDisk Cruzer - 64 and 256GB; both formated as NTFS; both working properly under Windows) didn't even show up. And after a reboot to try to fix that issue, the router went silent.

Is it possible that the USB devices short-circuited the device, somehow? Or was it just a coincidence that the router bricked/died at the exact same time?

Do a careful inspection of the router's USB ports and make sure the pins are not bend and touching each other.

 

[DAVID LONG]

<snip>


If the power supply was bad, would it still power on the router? Its behavior after it's powered on is what is unusual.

<snip>

Absolutely will still power on, but not function.

Have had that happen to three of my devices, over the years.

 

[L&LD]

Could the ISP be locking me out of changing settings? That has never happened before with the modem acting as a router.

This I've seen happen many times. And when you need them most, they only want to schedule an appointment. Usually for 'sometime next week'.

Get a stable replacement router and get the modem back into bridged mode. Sure, we can get ourselves in a jam with our own equipment, but then it is also up to us to get out of anything we may create or run into too.

As DAVID LONG mentioned, the power supply is the first suspect. See if you can get a quality replacement to at least test the 'dead' router with. Even if it isn't the actual cause, it would be worth keeping for the replacement (assuming it is compatible, of course).

 

[Ro berto]

hi all,
quick question regarding the reboot scheduler;

This enables the reboot scheduler for your
router.
The scheduler is set with a cron job via
init-start, as opposed to the WebUI setting
which uses an internal mechanism to reboot.

Is the cron job via init-start better compared to the webui setting?

 

[thelonelycoder]

hi all,
quick question regarding the reboot scheduler;

Is the cron job via init-start better compared to the webui setting?

Supposedly. For some this is the more reliable variant for rebooting than through the WebUI scheduler.
My own tests confirmed that. I am not sure this will still be the case with the upcoming 384.11 and later versions. @john9527 made a test build and found reasons why the WebUI scheduler behaved differently in some cases.
For the time being, the cron job version reboots the router more reliably.

Caution: Your RT86U has in some (unknown) cases the tendency to shut down and not boot up after. I have seen this myself on my unit, but not all users report seeing it on theirs.

 

[Ro berto]

Caution: Your RT86U has in some (unknown) cases the tendency to shut down and not boot up after.

so a manual boot up works? i.e. it will not brick, right?

 

[Asad Ali]

so a manual boot up works? i.e. it will not brick, right?

Yes a power cycle fixes that every time.

 

[Ro berto]

Caution: Your RT86U has in some (unknown) cases the tendency to shut down and not boot up after.

Confirmed, had to manually boot it up.

I disabled the atmt reboot scheduler and changed to the reboot scheduler in the webUI and ran a reboot test and it works.

Either way, thanks for the option

Ro berto

PS: on a side note, has anyone noticed there is a Cinco de Mayo (May 5 07:05:05 kernel) date on the System Log in the webUI after rebooting?

 

[thelonelycoder]

Confirmed, had to manually boot it up.

I disabled the atmt reboot scheduler and changed to the reboot scheduler in the webUI and ran a reboot test and it works.

Either way, thanks for the option

Ro berto

PS: on a side note, has anyone noticed there is a Cinco de Mayo (May 5 07:05:05 kernel) date on the System Log in the webUI after rebooting?

FYI: The glitch does not happen every time you reboot the 86U. Nothing's confirmed with one single test.

 

[Ro berto]

Nothing's confirmed with one single test.

I ran two tests and both didn't boot up (hehehe)

I'll give it a try with the webUI option, if it fails I'll switch back to the amtm option

If it helps, I can send syslogs so you can have a look.

 

[thelonelycoder]

If it helps, I can send syslogs so you can have a look.

That would be of no help to me, this is a hardware or some other fault and at the time it happens the error is not written to the syslog.
But you can try posting it anyway. Maybe this helps Asus or @RMerlin to track it down.

 

[Ro berto]

I am not sure this will still be the case with the upcoming 384.11 and later versions.

According to the changelog of 384.11 alpha there has been some fixes regarding the reboot scheduler in the WebUI:

- FIXED: Reboot scheduler would sometime get stuck or corrupt plugged USB drives. Now doing a more thorough shutdown of services, should hopefully make it more reliable.

 

[cmkelley]

PS: on a side note, has anyone noticed there is a Cinco de Mayo (May 5 07:05:05 kernel) date on the System Log in the webUI after rebooting?

That's the default date in the router's firmware. Asus' routers do not have a battery-backed clock, they loose the time when they are rebooted.

 

[sentinelvdx]

@thelonelycoder I don't want to use the reboot scheduler, but I would like to be able to use it's reboot process whenever I need to reboot it.
Is there a way to execute it to reboot my router?

Just to avoid using the webui reboot which I saw it's not so safe for us that we have several stuff running.

Sent from my SM-G965F Duos

 

[RMerlin]

@thelonelycoder I don't want to use the reboot scheduler, but I would like to be able to use it's reboot process whenever I need to reboot it.
Is there a way to execute it to reboot my router?

Just to avoid using the webui reboot which I saw it's not so safe for us that we have several stuff running.

Sent from my SM-G965F Duos

Quite the opposite. The webui reboot is the safest one, as it goes through a complete service shutdown, unlike what the reboot scheduler has been doing (up until 384.11, where I made it also use a proper rc-initiated shutdown).

 

[thelonelycoder]

Quite the opposite. The webui reboot is the safest one, as it goes through a complete service shutdown, unlike what the reboot scheduler has been doing (up until 384.11, where I made it also use a proper rc-initiated shutdown).

Which, I believe is "service reboot"?
amtm uses that as well.

 

[sentinelvdx]

Quite the opposite. The webui reboot is the safest one, as it goes through a complete service shutdown, unlike what the reboot scheduler has been doing (up until 384.11, where I made it also use a proper rc-initiated shutdown).

Oh I thought it was not safe because it was not unmounting correct the USB causing issues later with diversion, pixelserv, etc

Sent from my SM-G965F Duos

 

[thelonelycoder]

Oh I thought it was not safe because it was not unmounting correct the USB causing issues later with diversion, pixelserv, etc

Sent from my SM-G965F Duos

Diversion added an unmout script a while ago to properly stop its services. It apparently did not play as well with the WebUI reboot. Hence the amtm option. But John's latest and 384.11 alpha have modified code for a proper reboot when using reboot scheduler or the reboot command in the WebUI.

 

[sentinelvdx]

Diversion added an unmout script a while ago to properly stop its services. It apparently did not play as well with the WebUI reboot. Hence the amtm option. But John's latest and 384.11 alpha have modified code for a proper reboot when using reboot scheduler or the reboot command in the WebUI.

Great! I'll wait for gold version of 384.11 then thanks!

Sent from my SM-G965F Duos