WebUI not working after a while (RT-AC86u)

[Livin]

I have the same issue on 2 86U routers. This started with 384.17 I think, maybe .16, cant remember exactly. I use the WebUI less than once a week, maybe 2 to 3 times a month but for a while I was using it 2 to 3 times a week... and it seems like once every week or so I'd need to physically reboot a router to get to the UI. And this is still the case now as the reason I looked for this thread was I just rebooted my main router.

This is 100% definitely a bug/problem with the firmware as it didnt happen in .15 or maybe .16

 

[retzer]

Hello! I have a 68-U and I have always had problems getting into the WEbUI after a while. At first I thought it had something to do with my laptop (Win7 at first, later Win10) and was a caching issue. But lately I've come to realize it happens mostly when the router has been running for several days (maybe three weeks) without a reboot. Rebooting the laptop sometimes doesn't fix the problem but rebooting the router always fixes the problem. I haven't really pursued it much because in my world of things to worry about this ranks a bit low.

 

[Deleted member 51572]

I have the same issue on 2 86U routers. This started with 384.17 I think, maybe .16, cant remember exactly. I use the WebUI less than once a week, maybe 2 to 3 times a month but for a while I was using it 2 to 3 times a week... and it seems like once every week or so I'd need to physically reboot a router to get to the UI. And this is still the case now as the reason I looked for this thread was I just rebooted my main router.

This is 100% definitely a bug/problem with the firmware as it didnt happen in .15 or maybe .16

you're right, every so often the web UI my 1900P (68U) freezes on login (Merlin v380.70), but closing & reopening the browser (a second attempt) is always successful. i discovered that if i set Chrome to clear the router cookies upon exit, the web UI login bug goes away (clunky workaround, but it works). i bought a 86U as an upgrade to the 68U, but the former isn't ready for the real world, imo. i don't trust the 86U to reliably replace my 68U (1900P) at this point. as for the 86U's hanging web interface, the httpd process itself crashes, and must be restarted from an SSH command console (or reboot the router, which takes longer) to bring the 86U web UI back to life.

edit: oops, i meant to reply to @retzer not @Livin

 

[retzer]

you're right, every so often the web UI my 1900P (68U) freezes on login (Merlin v380.70), but closing & reopening the browser (a second attempt) is always successful. i discovered that if i set Chrome to clear the router cookies upon exit, the web UI login bug goes away (clunky workaround, but it works). i bought a 86U as an upgrade to the 68U, but the former isn't ready for the real world, imo. i don't trust the 86U to reliably replace my 68U (1900P) at this point. as for the 86U's hanging web interface, the httpd process itself crashes, and must be restarted from an SSH command console (or reboot the router, which takes longer) to bring the 86U web UI back to life.

edit: oops, i meant to reply to @retzer not @Livin

Yeah you are right! I forgot that I also can get into the WebUI by clearing the Chrome cookies. I notice the hangup occurs much more frequently since I moved to Win10 in January (RIP Win7). I'd like to get to the bottom of it but I'm growing a bit more impatient with age and clunky workarounds look better all the time!

 

[jsbeddow]

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.

Are you leaving the WebUI open on a long term/continuous basis by chance? This is a fairly long standing, well known issue, and basically serves as a reminder not to do that. Logout when done looking around in there, then log back in later if need be.

 

[Deleted member 51572]

Are you leaving the WebUI open on a long term/continuous basis by chance? This is a fairly long standing, well known issue, and basically serves as a reminder not to do that. Logout when done looking around in there, then log back in later if need be.

i'd rather the UI bugs be fixed, as I want to stay logged in. simple as that.

also, i consider the router to be more secure if i don't sign out, because only one user can login at a time. if another client station attempted to Sign In - while I am logged in - they are denied access... until i sign-out (or idle-out), which i don't do. and only i have physical access to the computer, so it's all good.

 

[L&LD]

@techcafe but then you're ignoring the fact that your 'one user' that is logged in securely may still be compromised with other methods and then still have full access to your entire network faster than you can say Oh! Snap!

Careful what you wish for, it isn't always what you think you need.

 

[Jack Yaz]

@techcafe but then you're ignoring the fact that your 'one user' that is logged in securely may still be compromised with other methods and then still have full access to your entire network faster than you can say Oh! Snap!

Careful what you wish for, it isn't always what you think you need.

There is a reason most secure systems (e.g. Online banking) enforce a non configurable idle timeout, after all!

 

[Livin]

you're right, every so often the web UI my 1900P (68U) freezes on login (Merlin v380.70), but closing & reopening the browser (a second attempt) is always successful. i discovered that if i set Chrome to clear the router cookies upon exit, the web UI login bug goes away (clunky workaround, but it works). i bought a 86U as an upgrade to the 68U, but the former isn't ready for the real world, imo. i don't trust the 86U to reliably replace my 68U (1900P) at this point. as for the 86U's hanging web interface, the httpd process itself crashes, and must be restarted from an SSH command console (or reboot the router, which takes longer) to bring the 86U web UI back to life.

edit: oops, i meant to reply to @retzer not @Livin

I replaced 2 68P w/ 2 86U and they have been MUCH better at everything... except the WebUI crashes.

@RMerlin anything we can do to help troubleshoot, and get a fix for, these WebUI crashes?

 

[dodge]

Are you leaving the WebUI open on a long term/continuous basis by chance? This is a fairly long standing, well known issue, and basically serves as a reminder not to do that. Logout when done looking around in there, then log back in later if need be.

I do that as well! As a control freak, I like to look at the stats every now and then and can't be bothered to logout and in. Just restarted the httpd service after WebUI crashed again this morning (not bad this time, ran for about a week or so before crashing).

Do you know why this is a long-standing issue?

i'd rather the UI bugs be fixed, as I want to stay logged in. simple as that.

also, i consider the router to be more secure if i don't sign out, because only one user can login at a time. if another client station attempted to Sign In - while I am logged in - they are denied access... until i sign-out (or idle-out), which i don't do. and only i have physical access to the computer, so it's all good.

To make it even more secure, you can permit which clients can access the WebUI. You could also logon to the WebUI via your phone's browser...

 

[TonyK132]

I have had this problem also. But ever since I've been doing an https service start everyday at 4am, I have not have a GUI problem.

 

[dodge]

I have had this problem also. But ever since I've been doing an https service start everyday at 4am, I have not have a GUI problem.

That'd be my last resort really. Trying the "don't keep the WebUI logged on" method to see how it goes.

 

[Livin]

I have had this problem also. But ever since I've been doing an https service start everyday at 4am, I have not have a GUI problem.

How? I dont leave mine logged in, ever... it has the timeout set to autolog out and I'm having this bug get worse!

thx

 

[john9527]

Just a random thought.....if the drop caches option is set (I think this is the Merlin default), the gui may be losing track of something it needs. I know the router will cache data used by the gui if allowed. It might be worthwhile to try setting this to off (don't drop caches), and see what happens.

 

[dodge]

How? I dont leave mine logged in, ever... it has the timeout set to autolog out and I'm having this bug get worse!
thx

In crontab e.g.

04 00 * * * service restart_httpd

would restart the httpd service at 4am daily.

Just a random thought.....if the drop caches option is set (I think this is the Merlin default), the gui may be losing track of something it needs. I know the router will cache data used by the gui if allowed. It might be worthwhile to try setting this to off (don't drop caches), and see what happens.

Where do you set this? Checking an older post says it's no longer available?

 

[Jack Yaz]

In crontab e.g.

04 00 * * * service restart_httpd

would restart the httpd service at 4am daily.

actually that would reset it at 4 minutes past midnight. you want

0 4 * * * service restart_httpd

 

[dodge]

actually that would reset it at 4 minutes past midnight. you want

0 4 * * * service restart_httpd

Haha my bad! Thanks.

 

[john9527]

Where do you set this? Checking an older post says it's no longer available?

Re drop_caches.....I stand corrected. You are correct. I didn't realize that the option had been removed from the HND routers.

 

[zz63]

It has happened to me 2 times in two weeks with rt-ac2900 (rt-ac86U).

I see that for years it has happened to more people but there is no solution, just restart the httpd service.

It seems to be the case with merlin firmware but not with stock firmware.

What firmware do you have?

I have the router in AP mode and connected a 4TB Toshiba 3.0 hard drive.

 

[Deleted member 51572]

I've discovered that if 'Auto Logout' (Administration, System, Basic Config) is set to a large value (960 minutes), the web UI stays logged in, as intended, and httpd does not crash. Setting the Auto Logout to zero (0) will cause httpd to crash after some random amount of time. Try setting Auto Logout to a large number.