search

gzenux / asuswrt-rtn18u

The UNOFFICIAL Asuswrt-Merlin ONLY for ASUS RT-N18U router.
https://gzenux.github.io/asuswrt-rtn18u
Other
62 stars 13 forks source link

GUI is slow and unresponsive #8

Closed Eldenroot closed 5 years ago

Eldenroot commented 5 years ago

I flashed your fw on my RT-N18u. I used Tomato fw before.

Everything is fine except one thing - sometimes the GUI is really slow and unresponsive. I have tried to reboot device but without any success. It happens only sometimes, tried in Google Chrome/Edge chromium/Firefox.

I do not how to reproduce. Any recommendation?

Eldenroot commented 5 years ago

OK, I am not alone - it is a bug with .12?

https://github.com/RMerl/asuswrt-merlin.ng/issues/326

better to wait for Asus to fix this.

@gzenux

maxbraketorque commented 5 years ago

If you are connecting to the router interface via https, then the slow, sometimes unresponsive behavior is a known issue as Merlin says a few posts after the one that you referenced. If you connect via http, the interface should be very responsive.

Eldenroot commented 5 years ago

I use only HTTP, anyway the GUI is slow (according to the post above I am not the only one)

Eldenroot commented 5 years ago

Enable QoS adaptive and try, it happens only with QoS senabled

maxbraketorque commented 5 years ago

ok. I have not tried with QoS enabled, but there are many people running QoS in Merlin 384.12. Have you tried clearing your browser cache as others have suggested? If that doesn't fix it, then it may be an issue specific only some routers.

gzenux commented 5 years ago

I can reproduce this issue with QoS enabled. According to Merlin's issue discussion, someone mentioned that Merlin 384.11_2 has no such problem.

It's very likely caused by commit f67ebf59ef and dbd4abf8f7, which solved CVE-2019-11477, CVE-2019-11478 and CVE-2019-11479. I can't figure out why these commits conflict with QoS feature and I'm not sure whether should revert these commits since they are security patches.

I would like to wait for Merlin to solve this issue. If you really need to enable QoS, my current suggestions are:

  1. Use previous release 384.10 (384.11 has already merged Merlin 384.12)

or

  1. Apply the following workaround to disable TCP SACK (needs to apply setting every boot) # echo 0 > /proc/sys/net/ipv4/tcp_sack

Please note that the GUI response is slower than #1 but a little faster than current state.(tested on my router)

Eldenroot commented 5 years ago

@gzenux - thank you for your input.

I disabled QoS for now (I have optic fiber connection 100/100 Mbps so I think it is not necessary to use QoS for now).

Let @RMerl solve this issue or wait for official Asus fix. In my opinion you should NOT revert these CVE commits, better to have slow GUI than security holes in our devices.

maxbraketorque commented 5 years ago

100/100 mbps are pretty reasonable up/down speeds. Unless you are continually using a good fraction of that bandwidth for file transfer, or are a really serious gamer, I don't think QoS is needed. I use BT heavily for anime, and I do my file transfer rate limits within the BT software rather than by QoS in the router.

gzenux commented 5 years ago

I think I find the solution. Tested on my router.

Reference: https://lkml.org/lkml/2019/6/26/163

Eldenroot commented 5 years ago

Great!

themiron commented 5 years ago

thanks, applied

maxbraketorque commented 5 years ago

Nice job. Do you know if this fix been identified for Merlin's FWs as well?

gzenux commented 5 years ago

@Eldenroot 384.11_2 now available and it has contained this bugfix. I'll close this issue if there is no more problem with it.

Eldenroot commented 5 years ago

I updated, feel free to update it. I will open a new ticket if anything :) thx!