Web management page not loading properly

[Ted Danson]

I've been noticing an issue over the past couple of months with the web management feature on my RT-AC5300. If I try to log in, the login page is fine and loads quickly. But the main management page after it will either take forever to load, load incomplete, load broken items (e.g. list of devices panel).

If I can click a link off of that page, same thing.

It gets to the point where I either SSH in and reboot, or just power cycle manually.

It's weird as the router is under absolutely minimal load. I'm on the latest firmware, though. Syslog shows nothing at all to point to a problem. Tried factory reset too.

Anyone experienced this or got an idea of what may be going on?

 

[RMerlin]

Use http. The https support in Asuswrt is quirky, and recent browser updates have somehow made the issue worse.

 

[Ted Danson]

Use http. The https support in Asuswrt is quirky, and recent browser updates have somehow made the issue worse.

Ah OK, yes I am using https so I'll switch that back for now. Though hope we can get https back properly at some stage. I was looking for the 384 fw but cannot find it in the downloads section. I only have 380.69_82 at the moment which I thought was the latest.

Thank you by the way RMerlin for everything you do for the community. Much appreciate it!

 

[NickBurns]

Strange enough. I am here now because my AC-5300 380.69_2 just dropped the 2.4Ghz band (WiFi logo upper right shows 2.4Ghz Channel 0) and the webGUI is slow.. painfully slow. Login page displays quickly but getting in was painful. There is nothing in the General Log to indicate there was ever an issue other than earlier today a rogue PPTPD intrusion attempt from the web which I get day in and out.

I am using HTTP for GUI access @ home; only HTTPS if I'm remote. @RMerlin are you suggesting HTTPS simply be disabled outright?

Feb 21 10:45:05 pptpd[946]: MGR: initial packet length 5635 outside (0 - 220)
Feb 21 10:45:08 pptpd[946]: MGR: dropped small initial connection
Feb 21 10:45:09 pptpd[10292]: CTRL: Client 164.52.6.146 control connection started
Feb 21 10:45:09 pptpd[10292]: CTRL: EOF or bad error reading ctrl packet length.
Feb 21 10:45:09 pptpd[10292]: CTRL: couldn't read packet header (exit)
Feb 21 10:45:09 pptpd[10292]: CTRL: CTRL read failed
Feb 21 10:45:09 pptpd[10292]: CTRL: Client 164.52.6.146 control connection finished

Around the time of failure the following two hosts, which are VMs apparently attempted discovery getting an offer and then NAKs. These servers are actually statically assigned (on the VM itself) so shouldn't even be doing DHCP. Will dive into why this is, but this is not the first co-incidence of this wrong server-ID and my total loss of 2.4Ghz and/or webGUI slowing to a crawl.

Feb 21 11:35:46 dnsmasq-dhcp[910]: DHCPDISCOVER(br0) 24:f6:77:31:fc:ba
Feb 21 11:35:46 dnsmasq-dhcp[910]: DHCPOFFER(br0) 192.168.1.170 24:f6:77:31:fc:ba
Feb 21 11:35:46 dnsmasq-dhcp[910]: DHCPREQUEST(br0) 192.168.1.218 24:f6:77:31:fc:ba
Feb 21 11:35:46 dnsmasq-dhcp[910]: DHCPNAK(br0) 192.168.1.218 24:f6:77:31:fc:ba wrong server-ID
Feb 21 11:58:04 dnsmasq-dhcp[910]: DHCPDISCOVER(br0) 08:3d:88:ab:e4:8b
Feb 21 11:58:04 dnsmasq-dhcp[910]: DHCPOFFER(br0) 192.168.1.28 08:3d:88:ab:e4:8b
Feb 21 11:58:04 dnsmasq-dhcp[910]: DHCPREQUEST(br0) 192.168.1.219 08:3d:88:ab:e4:8b
Feb 21 11:58:04 dnsmasq-dhcp[910]: DHCPNAK(br0) 192.168.1.219 08:3d:88:ab:e4:8b wrong server-ID

 

[RMerlin]

@RMerlin are you suggesting HTTPS simply be disabled outright?

No, you can keep both http and https enabled.