AC68U Frequently dying on me

[Preskitt.man]

I have an AC68U. Until about two weeks ago, I was using the 374.43 fork (and it's predecessors). Very stable.

I then switched to Merlins 378.56_2 build. To get there, I had to first install an stock ASUS build and then update to Merlin. Since then, the router has basically died on me about once a day. Both wifi & ethernet not available. Can't ssh into device. Sometimes, wifi still shows the ssid's (but can't connect to them), sometimes not even that. After a reboot, log doesn't show anything useful - it begins at the time of the reboot. For a couple of days, I set it to automatically reboot every day at 3am. Sometimes, router didn't even fully wake up from that - had to power cycle the router.

Nothing really interesting going on when this happens - just seems to go dead. Nothing really interesting in my configuration. Went to Merlin so I could name my clients and be on a thread that seemed to be moving forward more.

Anybody have any ideas. I like Merlin. This build has been available for some time, so I guess this is not a general problem. While extra features are nice, a stable connection is even nicer. Rebooting a router once a month or so is fine, but not every day. In all honesty, need to do something very soon - my boss (ie the wife) is really on my case - all she really wants is a to be able to access the internet).

 

[martinr]

I'm sure you would have done it but merely overlooked mentioning it, but would you just confirm that, after updating to 378.56_2, you restored the router to its factory default settings (and then reinstated your settings manually).

 

[Preskitt.man]

I'm sure you would have done it but merely overlooked mentioning it, but would you just confirm that, after updating to 378.56_2, you restored the router to its factory default settings (and then reinstated your settings manually).

Yes, I did. This has been very frustrating.

 

[gatorback]

Q1) Was the NVRAM reset after flashing firmware?
Q2) Can you eliminate heat as being a root-cause problem?
Q3) Can you run the system on any firmware to confirm (374.43?) that it is a SW and not HW problem?

 

[Preskitt.man]

Q1) Was the NVRAM reset after flashing firmware?
Q2) Can you eliminate heat as being a root-cause problem?
Q3) Can you run the system on any firmware to confirm (374.43?) that it is a SW and not HW problem?

Q1) No - not part of any instructions I saw. Have never done that in the past - don't know how to do it.
Q2) Heat not an issue - Router has plenty of air circulation and house is quite cool this time of year.
Q3) Don't know. Have not tried. Maybe next step as I did not have problem on 374.43 before all this began.

In the meantime, have again set the router back to factory settings and then did my setup again (manually). Will see where this take me.

 

[RMerlin]

Recent releases from Asus were gradually filling up RAM with debug logs they forgot to disable. Some were removed in 378.56_2, but a few mores were only removed in the current development code (380.57).

 

[Preskitt.man]

Recent releases from Asus were gradually filling up RAM with debug logs they forgot to disable. Some were removed in 378.56_2, but a few mores were only removed in the current development code (380.57).

1) Are you suggesting I go to to 380.57? I generally try to avoid development code in favor of stability. Course that's the problem I'm trying to solve.
2) Doesn't seem like a debug log would fill up and overflow in the course of less than two days

 

[RMerlin]

1) Are you suggesting I go to to 380.57? I generally try to avoid development code in favor of stability. Course that's the problem I'm trying to solve.
2) Doesn't seem like a debug log would fill up and overflow in the course of less than two days

It could. Monitor the content of /tmp after a few hours, you'll see if it's the case.

ls -l /tmp

The 380.57-alpha3 code is quite stable so far, and should be reliable enough to use. Next alpha might need more testing however, as it will merge a new GPL, with a new SDK and new wireless driver for the RT-AC68U.

 

[Preskitt.man]

It could. Monitor the content of /tmp after a few hours, you'll see if it's the case.

ls -l /tmp

The 380.57-alpha3 code is quite stable so far, and should be reliable enough to use. Next alpha might need more testing however, as it will merge a new GPL, with a new SDK and new wireless driver for the RT-AC68U.

Thanks, will monitor things first. If looks sketchy, will try 380.57.

 

[Preskitt.man]

Thanks, will monitor things first. If looks sketchy, will try 380.57.

For what it's worth, just did a df and /tmp shows only 1% full after my last reboot which was about 5 hours ago.

 

[RMerlin]

For what it's worth, just did a df and /tmp shows only 1% full after my last reboot which was about 5 hours ago.

Don't look at the percentage, look at the size of the files in it.

 

[gatorback]

Q1) No - not part of any instructions I saw. Have never done that in the past - don't know how to do it.
Q2) Heat not an issue - Router has plenty of air circulation and house is quite cool this time of year.
Q3) Don't know. Have not tried. Maybe next step as I did not have problem on 374.43 before all this began.

In the meantime, have again set the router back to factory settings and then did my setup again (manually). Will see where this take me.

With regard to Q1): https://www.dd-wrt.com/wiki/index.php/Asus_T-Mobile_Cellspot

Always perform a NVRAM reset after flashing firmware, reboot and allow 5 minutes to rebuild NVRAM variables.
** Power off the router
** Hold the WPS Button
** Power on the router and keep the WPS pressed for 10-15 seconds
** Reboot as necessary

This is quick and simple. Reconfigure the router manually. If the rebooting stops, then proceed to the icebox and reward yourself with a beverage of choice.

Q2) and Q3) were intended to prompt critical thinking (measurement \ experimentation) to isolate the issue.

 

[martinr]

With regard to Q1): https://www.dd-wrt.com/wiki/index.php/Asus_T-Mobile_Cellspot

Always perform a NVRAM reset after flashing firmware, reboot and allow 5 minutes to rebuild NVRAM variables.
** Power off the router
** Hold the WPS Button
** Power on the router and keep the WPS pressed for 10-15 seconds
** Reboot as necessary

This is quick and simple. Reconfigure the router manually. If the rebooting stops, then proceed to the icebox and reward yourself with a beverage of choice.

Q2) and Q3) were intended to prompt critical thinking (measurement \ experimentation) to isolate the issue.

Preskitt.man didn't mention in his initial posting he'd restored his router to factory default status after flashing with his current firmware, thereby clearing NVRAM, but he confirmed it in posting #3 above.

 

[Preskitt.man]

Don't look at the percentage, look at the size of the files in it.

Ok - but what size is the trigger point to be concerned about. just did a ls -lS /tmp and top files are:
-rw-rw-rw- 1 admin root 83668 Dec 12 20:53 upnpc_xml.log
-rw-rw-rw- 1 admin root 76063 Dec 13 10:14 syslog.log
This is after about 16.5 hours of uptime. At what point does size become worrisome?

 

[RMerlin]

Ok - but what size is the trigger point to be concerned about. just did a ls -lS /tmp and top files are:
-rw-rw-rw- 1 admin root 83668 Dec 12 20:53 upnpc_xml.log
-rw-rw-rw- 1 admin root 76063 Dec 13 10:14 syslog.log
This is after about 16.5 hours of uptime. At what point does size become worrisome?

83 KB and 76 KB is fine. Start worrying if they hit 20-30 MB.

 

[keyboard99]

Your symptoms sound exactly the same as what I get when I turn on the VPN function of the RT-AC68U. I'm not so savvy so don't know what to interrogate the device using those command. Going to keep watching this thread as I think it will solve my issues too as my thread hasn't had a reply so far, so thanks for posting.

 

[martinr]

Your symptoms sound exactly the same as what I get when I turn on the VPN function of the RT-AC68U. I'm not so savvy so don't know what to interrogate the device using those command. Going to keep watching this thread as I think it will solve my issues too as my thread hasn't had a reply so far, so thanks for posting.

As gatorback mentions above, have you eliminated heat as the cause?

As standard, the cpu seems to run at 80C. Whilst that might sound excessively hot, the vast majority of RT-AC68Us seem to run as smooth as silk. Regardless of that, if you see 80C for the cpu and in the 50s for the wireless chips, heat is not the problem. But it should be checked if only to rule it out.

 

[Preskitt.man]

83 KB and 76 KB is fine. Start worrying if they hit 20-30 MB.

Well yesterday, about two hours after my previous post, same thing happened again. System died. No connections via wifi nor ethernet. Could not ping the device. Reverted to the Fork code which had been stable for me. Will see how that goes. The day before, to give myself what I hoped was a better chance, I did a factory reset and then manually reset params. Didn't seem to help the situation. Everything was fine till it wasn't.

 

[RMerlin]

Well yesterday, about two hours after my previous post, same thing happened again. System died. No connections via wifi nor ethernet. Could not ping the device. Reverted to the Fork code which had been stable for me. Will see how that goes. The day before, to give myself what I hoped was a better chance, I did a factory reset and then manually reset params. Didn't seem to help the situation. Everything was fine till it wasn't.

Try the alpha 4 build I released this weekend. It fixes all the known logfile problems, in addition to switching the RT-AC68U to a new SDK. See if that helps.

 

[Preskitt.man]

Thanks - I will do that - but I do leave on a vacation tomorrow. I will wait till I return on the 28th to do so. I don't presume that the 2.0 boot loader is in any way the source of this problem. To get your latest code, I first had to load a release of the stock ASUS code to get the 2.0 boot loader. That was followed by a factory reset and the loading of your (Merlin) code.