Can't Login to GUI

[L&LD]

Updating from that firmware and doing a full reset (required, including formatting the JFFS partition on the next reboot) would solve many problems. Known and unknown.

 

[Mike S]

I have had the same problem for 10 months. Running RT-AC86U_384.14_0 for 10 months. Wonder if updating to the latest firmware solves the problem?

A better question would be whether going back to an older software release would solve the problem.

 

[Kanji-San]

A better question would be whether going back to an older software release would solve the problem.

I have seen this unresponsive GUI issue also on older firmware versions on the RT-AC68U. I have not seen it (yet) on the RT-AX88U. This might be router-specific.

 

[tejesh83]

TLDR: Still chasing the root cause and fix, but for my router it appears to be a memory leak causing the GUI and SSH to fail.

Gory details:

This started on only one of my ac86u routers recently about a month ago, but unfortunately, I made quite a few changes to the router and network setup at that time, so I'm not yet sure what specific change(s) are causing it. The good news, I have a near identical ac86u setup without the issue, so it should help troubleshoot. Also, prior to this, the router was rock solid with months and months of uptime, so it's very likely a firmware or config update I made at the time that's causing this.

A suggestion, in case you haven't already, turn up what's getting logged in syslog for clues:
Advanced Settings > System Log > Log only messages more urgent than > debug or all
I had mine set to debug.

In my case, the troublesome router seems to last about a week or 2 before starting to glitch. Yesterday for example, the GUI was unreachable, and I was able to initiate an ssh connection, but the shell prompt wouldn't load. Devices behind the router however were still able to connect to the internet, however though those forced behind the router's client vpn connection did have some intermittent connectivity issues. It's a remote device, so I had someone physically power toggle the device, and the GUI and SSH came back up. The good news, this time I was able to recover enough logs to confirm my suspicion, that at least for my device, it seems to be caused by a memory leak. I had numerous kernel panics in the logs and a few specific out of memory errors being reported. Note, I had seen intermittment kernel panics in the log before, but this was the first time the logs captured the specific out of memory errors, so it does seem when this issue happens it doesn't always get logged. e.g. OOM error:

kernel: pidof triggered out of memory codition (oom killer not called): gfp_mask=0x201da, order=0, oom_score_adj=0

Leading up to this, I had noticed that the router was consuming more memory since I made changes a month ago. Everytime I logged into the router, I also saw the memory usage climbing and getting close to 100%. As a precaution, I turned on swap on my usb stick. But after a week, same issue, the router crashed, and this time it took my usb drive with it (or at least I thought). With the drive no longer being detected by the router, I figured it was a good test to see if the custom scripts I had running were causing the issue. But, sure enough a week later the router crashed again. The good news, when power cycling the router this time, the usb stick came magically back to life.

So here's what I'm trying now:

1. Turned off the VPN server feature.
2. Turned off the Traffic Analyzer statistics feature.
3. Under Administration/Privacy, I withdrew consent. This turned off DDNS and QOS, and possibly other features I may have accidentally turned on.
4. I then turned only QOS back on.
5. I formatted the JFFS partition and copied back only my vpn settings that got lost in the wipe.
6. I formatted the USB Drive (using amtm)
7. I then reinstalled x3mrouting and flexqos scripts since I ruled them out as the culprit.

A lot of changes, but its probably my last resort before driving to the remote location (2 hours) and doing a full factory reset and nvram wipe on the router. At this point, the router with the issue and without are configured with the same features enabled, so fingers crossed it does the trick.

I did log into the router to check mem usage this morning, and unfortunately it has already climbed a couple points, but hopefully it stabalizes. Also since I've turned off a few features, there's a bit more memory headroom, so I suspect if there still is a memory leak, it will take a bit longer than the week or 2 it was taking prior to crash this time around.

I'll keep you guys posted, but it may be a few weeks before I have any news to report. Happy chasing!

 

[Viktor Jaep]

I'll keep you guys posted, but it may be a few weeks before I have any news to report. Happy chasing!

I can't speak for those not running a VPN Client, but I really think OpenVPN has something to do with it. After a reboot, the VPN traffic is speedy and getting good rates... after a week or so, it drastically slows down and am only pulling about 5Mbps up and down... the CPU seems to be pegged at almost 100% trying to sustain this traffic. At this point, the GUI is extremely sluggish to the point where it's timing out in the browser. This, I believe, leads to the GUI just becoming completely non-responsive, and am just catching a glimpse as to what happens prior. Took some screenshots of my router running 6 days and 12hrs. Very light traffic... CPU is pegged. I'm not familiar with ways to troubleshoot this, but running the TOP command shows the VPN client hogging the most for the very little traffic it is handling.

 

[tejesh83]

I can't speak for those not running a VPN Client, but I really think OpenVPN has something to do with it. After a reboot, the VPN traffic is speedy and getting good rates... after a week or so, it drastically slows down and am only pulling about 5Mbps up and down... the CPU seems to be pegged at almost 100% trying to sustain this traffic. At this point, the GUI is extremely sluggish to the point where it's timing out in the browser. This, I believe, leads to the GUI just becoming completely non-responsive, and am just catching a glimpse as to what happens prior. Took some screenshots of my router running 6 days and 12hrs. Very light traffic... CPU is pegged. I'm not familiar with ways to troubleshoot this, but running the TOP command shows the VPN client hogging the most for the very little traffic it is handling.

View attachment 27199

View attachment 27198

Have you tried turning up the verbosity under vpn settings and seeing what pops up in syslog for clues?

I've run a vpn client 24/7 and have never pegged the cpu with my setup even at full bandwidth upto 200Mbps. I've even run that setup for months on end without reboot and no issues in the past.

Update on my scenario, the memory usage continued to climb everyday, hitting 81% this morning (up 11% over the last few days), but cache/buffer usage was flat. If I let the trend continue, I'll prob be out of memory in 5 days. Comparing processes running and used memory over time, nothing has climmbed, so it seems the leak is occurring in the kernel? In my syslog, I did see the kernel report a few more dcd crashes. So I suspect this has something to do with it, and per other forum post those seem to be tied to trend micro and qos with no solution .

I've tweaked my qos settings, hoping it might resolve the crashes. I was using adaptive with fq_codel, so will try sfq since I believe that's what the stock firmware uses instead to see if it helps. My mem usage is hovering around 70% after making the change and rebooting, so let's see what happens in a few days.

 

[Viktor Jaep]

Have you tried turning up the verbosity under vpn settings and seeing what pops up in syslog for clues?

That's a great idea... I've moved it up from 3 to 5... 6 was just too much unnecessary chatter... but nothing to report as of yet. I have also disabled regular cache flushes based on some other threads that were saying that perhaps the httpd service is unable to read or losing cached settings when things get flushed (under tools->other settings)

 

[Viktor Jaep]

So here's a quick update... I just recently acquired a brand new RT-AC86U, and loaded Merlin 384.19 on it from scratch, reconfigured everything from scratch, and only have absolute minimal functionality running. I can't get past about 4-5 days before I'm greeted with the blank GUI. For the first time, this command worked, and let me gain access of the UI:

service restart_httpd

 

[tejesh83]

I had no luck here either with different qos settings. Using sfq bought a few more days, but eventually it too succumbed to the mem leak plauging my router. The syslog continued to be littered with dcd crashes that have been reported by many ac86u users, as well as some random qos errors, so the trend micro services seem the likely culprit. It seems plausible since prior to turning on qos (the only trend micro feature I have enabled), I've gone months without issues or rebooting the device.

I gave up chasing a fix. Because the ac86u reboot scheduler is a bit finicky on my router and randomly hangs off instead of turning back on, I picked up an ip power switch (ezoutlet3) to power cycle the plug/router if the internet connection goes down and set the router to reboot a couple times a week as a workaround. Been a couple weeks and all seems stable so far.

 

[redpants]

I updated to RT-AC86U_384.19_0 yesterday. So far so good

 

[redpants]

And now the problem is back :/

 

[DCswitch]

I was able to resolve the issue. I hope this helps since I went through the same problem of not being able to login into the GUI of an Asus RT-AC68U. This was the first time it happened to me and I have been upgrading the firmware on this router for years with no issues.

The recommendation is to Reset the router (hopefully, you took screenshots of all your settings as well as saving your Settings in the Administration section), but I thought it was a simple press the Reset button in and hold it. That didn't work for me, so I looked it up on the web and Asus says in order to do a hard reset:

Turn off the router, hold the WPS button in, turn router back on (keep holding WPS button), and release the WPS button after the power LED stops flashing. This worked for me. I'm able to get back to the GUI with no issue now and I'm on the current RT-AC68U_386.1_0.zip firmware.

[Wireless Router] ASUS router Hard Factory Reset - Method 1 | Official Support | ASUS Global

[Wireless Router] When Standard Reset Isn’t Working: Hard Factory Reset - Models list | Official Support | ASUS Global

 

[L&LD]

@DCswitch welcome to the forums.

Good first post, reinforcing the WPS method works wonders vs. the effectively ineffective 'Reset button' method in 2021.

 

[SR-G]

Exact same problem for me now on RT-AC88U

I've never encountered this problem a single time until today.
I've just upgraded from 386.14_2 to latest 386.2_4

And now i constantly have this problem (even after a software reboot or a hardware reboot).
Network is however still working, including connection to the router through SSH with ssh admin@192.168.8.1 (my router's IP).

When i enter the GUI, i have the login screen :

But after that, whatever the computer is, whatever the browser is, whatever the connection is (WIFI or RJ45), i have the same behavior : a fully blank screen.

If a "service restart_httpd" through SSH :
- the loading page is immediately shutdown in the browser
- once the page has been refreshed in the browser, i have again the login page
- but when i log in, i have the exact same behavior another time

There is nearly nothing in the console, except sometimes this :

So now i'm totally stuck (and i can't even downgrade as even after a full (electrical) reboot), i have again and again the same behavior.
And i really don't have time to reset everything just in case it would solve the issue (i bought that Asus router to not have to loose time with that kind of problems).

If i try the android app, it's a bit better but not 100% working compared to before :
- login is inconsistent (sometimes it works, sometimes it doesn't)
- a very few number of screens are working (like the WIFI status with "excellent" dumped inside it)
- but many features are not working : the list of connected devices is only showing the router itself (and not all the other devices), the graph with bandwidth on the main dashboard page is blank, and so on.

Any ideas ?

 

[ColinTaylor]

I've never encountered this problem a single time until today.
I've just upgraded from 386.14_2 to latest 386.2_4

There's no such version as 386.14_2 so I assume you mean 384.14_2 from over a year ago. There is a warning in the 386.1 release notes that upgrading from the 384 release will involve "database maintenance on first boot" that "can take anywhere from 5 minutes up to an hour". However, other forum members have reported it actually taking many hours to complete.

 

[SR-G]

Indeed, sorry for the typo, i was willing to say 384.14_2 -> 386.2_4.

Ok, good to now, so let's wait...

edit : after something like 90', service has indeed been restored, so it's as you were saying a different problem than what was discussed in this topic (only related to the upgrade on my side), even if the symptoms are the same (and if that "rebuild on first boot" behavior has quite unexpected side-effects about the UI).

 

[matt_bloke]

Hi,
Sounds like a similar problem to me. I have upgraded from 384.14_0 to 386.2_4 on AC88U.
Router working but web UI is non functioning.

I'll wait sometime and see if the issue resolves itself.

Regards

Matt

 

[matt_bloke]

Hi,
Sounds like a similar problem to me. I have upgraded from 384.14_0 to 386.2_4 on AC88U.
Router working but web UI is non functioning.

I'll wait sometime and see if the issue resolves itself.

Regards

Matt

This seems to have resolved itself now.

 

[Hazel]

For anyone who just upgraded from 384.x or prior and has no access to the WebUI anymore, please read the changelog next time:

There is a warning in the 386.1 release notes that upgrading from the 384 release will involve "database maintenance on first boot" that "can take anywhere from 5 minutes up to an hour". However, other forum members have reported it actually taking many hours to complete.

Thank you.

 

[matt_bloke]

For anyone who just upgraded from 384.x or prior and has no access to the WebUI anymore, please read the changelog next time:



Thank you.

Fair point. I did read the notes but looks like not carefully enough.

Thanks