What's new

WebUI not working after a while (RT-AC86u)

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

dodge

Occasional Visitor
Recently got a RT-AC86u and installed with the latest Merlin (384.18), and noticed WebUI being unresponsive after a while. Restarting the httpd service fixes this (service restart_httpd) as per the forums, but wondering why is this happening? Is the ASUS code still buggy after all these years?

Was previously on an RT-AC68u and had no such issues.
 
It's not a common issue.
I have certainly seen it happen once or twice in a couple of years of ownership, but the 86U will run for weeks at a time between reboots, and I'll never see this.
Maybe just an unlucky run for you?

It is possibly the result of httpd being booted from memory to make room for something else. If you are running at a high level of RAM utilisation, then losing come processes could be a problem.

I have recently switched to using the new "cake" qos, qhich has allowed me to withdraw permission for all the Trend Micro services. These are notorious memory leakers/hogs and the source of many issues.

(eg. my memory usage would tart at 85% on the fresh reboot and slowly climbs to 95%, while with no trend running, it starts at 50% and climbs to maybe 65%)
 
I should add that when the WebUI is unresponsive the router is otherwise still fine (clients can still access the Internet, SSH works etc.).

Have noticed RAM usage unusually high for the past few days (only started using the router 4 days ago and still tweaking it). It's now about 65%. Don't use Trend Micro yet, though was planning to use it for time-based access for some of the clients.

Any suggestions here? Using Diversion & YazFi as well.
 
Using Diversion & YazFi as well
As a test, personally, I wouldn't be "blaming" the router or firmware until I was sure it is not a 3rd party script causing your issues.
I know LOTS of people use those, but it can come down to how they are configured.
If you realty want to properly troubleshoot a repeating problem, then start with the basics. Reset the router. Reconfigure manually. Don't run anything "extra" until you are sure the base is stable. Add things one at a time allowing lots of time (weeks even) between additions.
 
Update to my situation - mem usage has stabilised between 80-90% (as expected of the 86u judging from previous posts), however the WebUI still hangs, and I have to force a manual httpd service restart to reactivate.

Any more ideas? No insights from dmesg or the syslog. Doesn't look like a mem leak now, and I'm too lazy to start configuring from scratch again. May just cron a daily httpd restart as a workaround.
 
Merlin GUI is crashing on my RT-AC86U routers as well. I did duplicate the exact setup on a borrowed RT-AC68U router and there is no issue whatsoever there. Tested it for a week, not a single crash. Asus base firmware for RT-AC86U plus Merlin on top breaks something on this specific model in some conditions. Asuswrt stock for RT-AC86U doesn't suffer from GUI crashes. Not sure what to recommend to you @dodge. My solution is to replace RT-AC86U routers.
 
Merlin GUI is crashing on my RT-AC86U routers as well. I did duplicate the exact setup on a borrowed RT-AC68U router and there is no issue whatsoever there. Tested it for a week, not a single crash. Asus base firmware for RT-AC86U plus Merlin on top breaks something on this specific model in some conditions. Asuswrt stock for RT-AC86U doesn't suffer from GUI crashes. Not sure what to recommend to you @dodge. My solution is to replace RT-AC86U routers.
i get 0 httpd crashes on my 86U and i probably abuse the webui more than most.
 
Not sure where else to look

Reset the router, format jffs, do not enable custom scripts. Start with clean Merlin and test for a week or so. I highly respect all the coders work, but since Merlin introduced addons API the overall stability of the firmware on RT-AC86U got worse. I had Skynet and Unbound installed with no addon pages. htppd crashes were rare. I did test Jack's scripts too. The more addon pages start appearing the often httpd crashes. Local "part of the furniture" members usually blame the user, but even Jack included httpd restart shortcut in his own scMerlin script. Quick search here on SNB shows the reason why. I suspect the main GUI page rework with internet meter also has something to do with httpd crashes. Could be wrong, but I don't remember restarting the service on 384.14 or earlier Merlin versions. This is not a complaint. I can't complain about something provided for free. Due to lack of free time lately my quick solution was to replace the cursed RT-AC86U routers with something else. The GUI on different routers may look the same, but underneath the kernel, drivers, components are all different. I found httpd doesn't crash on borrowed for testing RT-AC68U. Even packed with addon pages from scripts I don't need.
 
The scMerlin script was provided from April of 2019 and works on RMerlin firmware 380.68 or newer. This wasn't a response to any amtm scripts or GUI add-ons at all (which were introduced together after the RMerlin 384.15_0 release final firmware).

The overall stability of all supported RMerlin/amtm routers has gotten better, not worse, since amtm + scripts were made available, together.

Sure, users can misconfigure or mismatch scripts that shouldn't be used together, but that is part of the learning process, not a state of the firmware, per se.

The recipe for a stable router and a fast, reliable, and responsive network hasn't changed.
  • Flash the RMerlin firmware you want to use first (multiple times, if necessary. Sometimes the second or third flash 'sticks' better).
  • Reset the router to factory defaults via the WPS, reset button, and GUI methods. (Note, I flash the same firmware in-between the different resets at least once).
  • Make sure to check the 'Initialize all settings...' checkbox via the GUI method.
  • Make sure to check the 'Format the JFFS partition on the next reboot' checkbox and then hit 'Apply' at the bottom of the page. Now, reboot the router 3 times in the next 15 minutes or so. Making sure to wait for 5 to 10 minutes between reboots.
  • Use a new, never before used/seen, by any of your client devices on any network (yours or someone else's), SSID that is 8 characters long (not longer or shorter), and adheres to the conditions below.
  • Make sure the SSID and the username and passwords used are strictly alphanumeric characters with no spaces, no punctuation, no special characters, and no smiley faces. Make sure the username and password for the router are 16 characters long (max) too.
  • Set the router to the M&M Config defaults (please see my signature for that guide and others too).
  • Do not import a backup config file. Do not 'blindly' use old settings/options that may have worked before in an older firmware or other-model router.
  • Do not use an 'app' to pick the correct channel to use.
  • Do not re-use a USB drive that was used for amtm previously without first saving the data on it (if needed) and formatting it on a PC as NTFS. (Note; when you insert it into the router, you will use amtm to format it to Ext4 w/journalling and also create a 2GB swap file too before installing any other scripts. See the same link in my signature below for the amtm Step-by-Step guide for more details. And remember, with RMerlin firmware 384.15_0 or later, you can skip the part in the guide where it says to install amtm (it is already installed).
  • After the router is fully set up as above and you have finished changing settings in the GUI, reboot the router after 15 minutes or more uptime. Then, after an additional hour of uptime, reboot it once more. This is how I leave a newly created network for my customers and rarely do I ever have to return to reconfigure/troubleshoot further.
HTH.
 
HTH is a good ending. Unfortunately, it doesn't. In 384.18 release thread only, quick browsing the posts there - 4 times mentioned GUI unresponsive, service restart or router reboot needed. Searching SNB for "restart_httpd" shows multiple separate threads for GUI unresponsive. A fellow with multiple RT-AC86U reports the same issue in AP mode. All those routers must be misconfigured. What is there to configure so much in AP mode, btw? This is why Jack included httpd restart in scMerlin script. He just offers a workaround to a well known firmware bug.
 
@dodge Are you using the mobile app by any chance. I had similar issue recently where I couldn't even get to web ui login page after I used the app. It used to happen every time. Not happening anymore, i guess app got updated or something as I haven't made any changes.
 
The overall stability of all supported RMerlin/amtm routers has gotten better, not worse, since amtm + scripts were made available, together.

Alright, I'll see if I can find some time over the weekend to redo everything as per your steps.

@dodge Are you using the mobile app by any chance. I had similar issue recently where I couldn't even get to web ui login page after I used the app. It used to happen every time. Not happening anymore, i guess app got updated or something as I haven't made any changes.

WebUI access is only via my PC.
 
Have noticed this a time or two since going to .18. Dropped back to .17 last night, will keep an eye on it for a few days.
 
Latest update - no recurrence of WebUI hanging since previously reported. Uptime now nearly 7 days. Mem usage hovering at ~87%. Looks like it's settled down. Will continue monitoring.
 
Another update though semi-related to the WebUI crashing (it did crash twice since posting the above) - hard rebooted the router after about a week (turned off the power as had to relocate the router) and lo and behold - the router reset itself back to defaults :-/

Never had these issues with the 68u previously. So I started reconfiguring from scratch again, and let it sit for 2 days. No addons yet. All good.

Installed Diversion this morning, and WebUI was not responsive a short while after. Wasn't a mem leak as mem usage was ~65% (I leave the WebUI open and check every now and then). Install was via amtm. Default settings with YT blocking turned on. Only other setting I played with was enabling (and then disabling) the WebUI Diversion tab.

I'll try @L&LD's suggestions above to reset/reflash.
 
Another update though semi-related to the WebUI crashing (it did crash twice since posting the above) - hard rebooted the router after about a week (turned off the power as had to relocate the router) and lo and behold - the router reset itself back to defaults :-/

Never had these issues with the 68u previously. So I started reconfiguring from scratch again, and let it sit for 2 days. No addons yet. All good.

Installed Diversion this morning, and WebUI was not responsive a short while after. Wasn't a mem leak as mem usage was ~65% (I leave the WebUI open and check every now and then). Install was via amtm. Default settings with YT blocking turned on. Only other setting I played with was enabling (and then disabling) the WebUI Diversion tab.

I'll try @L&LD's suggestions above to reset/reflash.
I very much doubt this has anything to do wether Diversion is installed or not.
 
For what it is worth, my GUI will occasionally freeze or only half the page loads. F5, Shift F5, Ctrl F5 does not help. Most times, if I close the browser altogether and reopen the browser and navigate back to the router phone screen, all is fine.
 
fwiw, I did a 'hard factory reset' (method 2) on my RT-AC86U a few days ago, with Asus stock firmware (version 384.81369) which, to my delight, seems to have resolved the hanging UI issue (httpd crashing). i keep the web interface open with an idle timeout of zero (disabled). httpd crashed after few hours and always overnight: UI became unresponsive, requiring a service restart_httpd in the morning. but httpd hasn't crashed since doing the hard factory reset.

according to Asus, just pressing & holding the reset button on the back of the router may not properly restore factory defaults. a 'hard factory reset' is to: power OFF the router; press & hold the WPS button; power ON router while continuing to hold down WPS. the power LED will light up briefly then go out again, then release the WPS button. finally, power OFF the router, wait a few seconds... then power ON again. all LEDs will illuminate as the router does a 'hard reset'. a few minutes later, your 86U should be reverted to factory defaults.

this hard reset method is also covered elsewhere in the forum, but i'm posting it here as one possible solution to the hanging UI issue. seems to have worked with my RT-AC86U, so far.

oh and memory usage has also stabilized at around 300MB since the hard factory reset. before doing the reset, memory usage would increase over the hours, as high as 475MB. that was with factory defaults, wifi turned off and only 1 wired client connected for testing & monitoring.

final update: i'm sorry to report that httpd has just crashed again (web UI unresponsive). service restart_httpd brings the UI back to life as usual. same Asus firmware .81369. after the initial hard reset, the UI did stop hanging for a few days. i rebooted the 86U last night, and now httpd is back to hanging after some random hours of uptime.

maybe i'll just keep downgrading until i find a firmware version that is reasonably stable? i mean, this is ridiculous.
 
Last edited by a moderator:

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top