I'm fully aware that the ASUS GT-AC5300 router is *NOT* supported by the RMerlin's F/W, but I'll describe here a problem that I found today just in case it's related to similar issues posted here also in this forum with other ASUS routers' WebUI becoming unresponsive or inaccessible when using RMerlin's F/W, so please bear with me if you can. Otherwise, one can simply ignore this post, move on, and go on your merry way... No harm, no foul.
This is the context of what happened. Earlier this evening, I had just finished making some configuration changes to the OpenVPN Server on the GT-AC5300 router for a friend of mine (who recently bought it brand new), and I was testing it to verify its functionality and speed (just FYI, the router is running the latest available ASUS stock OEM F/W "3.0.0.4.384.82037" version). Everything was working well so I logged out from the WebGUI; but then, just to double-check some settings and make a few notes for future reference, I logged back in via the router's WebUI (again with my PC still connected locally via an Ethernet LAN port), and after entering the username & password (which have not been changed for about 2 weeks), the next webpage (http://{LAN_IP}/GameDashboard.asp) was very slow to come up and did only partially. I waited for about 2-3 minutes and then decided to put that aside, and I instead logged in via an SSH session (fortunately, I had already previously enabled & set up the SSH server for LAN access). I poked around the router looking for the usual suspects: very low free RAM, high CPU loads, low NVRAM remaining, etc., and the only thing that jumped at me when looking at the list of currently running processes (using the htop utility) was this NVRAM call:
1467 Admin4Ni 20 0 2960 652 540 S 0.0 0.1 0:00.01 nvram show
And this process was just showing up there in a "sleep" state and not completing execution, which should *not* happen. AFAIK, this type of call should just be an extremely short "blip" in the list of active processes. IMO, this process was in a "hang" state (in a deadlock perhaps?) which seems to be causing, or at least related to, the WebUI not functioning properly. While looking around further, I also took the 2 screenshots that I've attached to this post just to show the process as it was just there "hanging" for at least 11 minutes (shots were captured ~11 minutes apart).
Finally, just to verify my assumption, I sent a "kill -9 1467" command via the SSH terminal, after which I logged back in via the WebUI, and then everything was working normally; the router's webpages were very responsive as expected and without any loading issues whatsoever.
I realize that this might simply be an issue found on this particular ASUS router, or perhaps this specific line of ASUS model. Or, it's possible that these 2 unrelated events just happened around the same time by coincidence. But, just in case it's none of those possibilities, I thought I'd share my observations here so for those experiencing issues with the WebUI becoming unresponsive, perhaps you can be on the lookout for the same or similar "hang" processes.
BTW, I have experienced this same "unresponsive WebGUI" issue with my own personal router (RT-AC86U) only 3 times since I bought it ~2 years ago, and I have simply sent the "service restart_httpd" cmd via an SSH session every time, and this always fixes the problem. Now, I'll be myself on the lookout for any "hang" processes if it happens again.
This is the context of what happened. Earlier this evening, I had just finished making some configuration changes to the OpenVPN Server on the GT-AC5300 router for a friend of mine (who recently bought it brand new), and I was testing it to verify its functionality and speed (just FYI, the router is running the latest available ASUS stock OEM F/W "3.0.0.4.384.82037" version). Everything was working well so I logged out from the WebGUI; but then, just to double-check some settings and make a few notes for future reference, I logged back in via the router's WebUI (again with my PC still connected locally via an Ethernet LAN port), and after entering the username & password (which have not been changed for about 2 weeks), the next webpage (http://{LAN_IP}/GameDashboard.asp) was very slow to come up and did only partially. I waited for about 2-3 minutes and then decided to put that aside, and I instead logged in via an SSH session (fortunately, I had already previously enabled & set up the SSH server for LAN access). I poked around the router looking for the usual suspects: very low free RAM, high CPU loads, low NVRAM remaining, etc., and the only thing that jumped at me when looking at the list of currently running processes (using the htop utility) was this NVRAM call:
1467 Admin4Ni 20 0 2960 652 540 S 0.0 0.1 0:00.01 nvram show
And this process was just showing up there in a "sleep" state and not completing execution, which should *not* happen. AFAIK, this type of call should just be an extremely short "blip" in the list of active processes. IMO, this process was in a "hang" state (in a deadlock perhaps?) which seems to be causing, or at least related to, the WebUI not functioning properly. While looking around further, I also took the 2 screenshots that I've attached to this post just to show the process as it was just there "hanging" for at least 11 minutes (shots were captured ~11 minutes apart).
Finally, just to verify my assumption, I sent a "kill -9 1467" command via the SSH terminal, after which I logged back in via the WebUI, and then everything was working normally; the router's webpages were very responsive as expected and without any loading issues whatsoever.
I realize that this might simply be an issue found on this particular ASUS router, or perhaps this specific line of ASUS model. Or, it's possible that these 2 unrelated events just happened around the same time by coincidence. But, just in case it's none of those possibilities, I thought I'd share my observations here so for those experiencing issues with the WebUI becoming unresponsive, perhaps you can be on the lookout for the same or similar "hang" processes.
BTW, I have experienced this same "unresponsive WebGUI" issue with my own personal router (RT-AC86U) only 3 times since I bought it ~2 years ago, and I have simply sent the "service restart_httpd" cmd via an SSH session every time, and this always fixes the problem. Now, I'll be myself on the lookout for any "hang" processes if it happens again.
