What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

GUI exceptionally slow sometimes

JaimeZX

Senior Member
So. Subject line captures the essence. All seems well, but sometimes the router GUI is *exceptionally* slow to respond, even as SSL access seems plenty fast. When I say the GUI is slow, sometimes the browser times-out. Thoughts?

I just did the L&LD reset two weeks ago. Back to stock + Diversion + Skynet since then.
 
I assume you have a swap file installed using the amtm menu, correct?

Do you have the option to Flush Memory Buffers to 'yes'? Set that to 'no' and reboot the router.
 
Re: amtm swap: Correct.
Q: Where do I find that setting?

Edit: haven't found the setting yet. Rebooted. Still timing out. :wtf:
 
Last edited:
OK. On the off chance that the browser "attempting TLS handshake" forever meant the HTTPS connection was part of the problem, I managed to get far enough into the GUI to change it from "HTTPS" to "BOTH."

BOY THE GUI IS HELLA FAST NOW.

I wonder why HTTPS slowed to a crawl? Unusable!
 
OK. On the off chance that the browser "attempting TLS handshake" forever meant the HTTPS connection was part of the problem, I managed to get far enough into the GUI to change it from "HTTPS" to "BOTH."

BOY THE GUI IS HELLA FAST NOW.

I wonder why HTTPS slowed to a crawl? Unusable!

Glad you found the culprit. Sorry I couldn't reply earlier. The setting you want to change is located in Tools, Other Settings, under the section Advanced Tweaks and Hacks. Setting the 'flush RAM buffers' to 'No' makes the router and the whole network faster.
 
According to the Googles, slow-GUI-over-HTTPS is a known issue.

Edit: OK flushing off. :)
 
OK. On the off chance that the browser "attempting TLS handshake" forever meant the HTTPS connection was part of the problem, I managed to get far enough into the GUI to change it from "HTTPS" to "BOTH."

BOY THE GUI IS HELLA FAST NOW.

I wonder why HTTPS slowed to a crawl? Unusable!

Yesterday for the first time I had the problem you described with tls handshake going on forever and page wouldn’t load. It’s a new issue for me. 384.9. Refreshing browser and clearing cache had no effect but waiting a couple minutes it eventually unstuck itself and router GUI loaded back to login page.
 
OK. On the off chance that the browser "attempting TLS handshake" forever meant the HTTPS connection was part of the problem, I managed to get far enough into the GUI to change it from "HTTPS" to "BOTH."

BOY THE GUI IS HELLA FAST NOW.

I wonder why HTTPS slowed to a crawl? Unusable!
Since you run Pixelserv-tls, you can easily create a signed certificate for your router using the instructions here:

https://github.com/kvic-z/pixelserv...ixelserv-CA-to-issue-a-certificate-for-WebGUI

Assuming you’ve also imported the Pixelserv CA cert to you devices, https should no longer be a problem. Or see here: https://github.com/kvic-z/pixelserv...ificate#import-pixelserv-ca-on-client-devices
 
Generating your own CA + certificate will resolve the issue. Why is the self-generated certificate causing issues with Chrome, I have no idea. I suspect Chrome is trying to do something to establish a chain of trust, and this causes Chrome itself to hang.

There was a similar issue with Firefox, resolved in 384.10 (you have to re-generate a new certificate however). It's a known bug in Firefox that was filed 3 years ago, and apparently the Firefox devs never fully fixed it...
 
Generating your own CA + certificate will resolve the issue. Why is the self-generated certificate causing issues with Chrome, I have no idea. I suspect Chrome is trying to do something to establish a chain of trust, and this causes Chrome itself to hang.

There was a similar issue with Firefox, resolved in 384.10 (you have to re-generate a new certificate however). It's a known bug in Firefox that was filed 3 years ago, and apparently the Firefox devs never fully fixed it...

Happened to me with both Firefox and Safari on MacOS despite that weeks ago I had already self-generated certificate so it was permanent.
 
Happened to me with both Firefox and Safari on MacOS despite that weeks ago I had already self-generated certificate so it was permanent.

It must not just be self-generated, it also needs to have a proper trust path, i.e. you need to have a signing CA imported in your browser.

I have zero performance issues here since I started managing my own CA at home.
 
It must not just be self-generated, it also needs to have a proper trust path, i.e. you need to have a signing CA imported in your browser.

I have zero performance issues here since I started managing my own CA at home.

Uncertain how I should import signing CA to browser? I had done the steps below:

1. Went to WAN DDNS page
2. Select Persistent Auto-generated
3. Select Generate a new certificate: YES and click Apply
4. Select Export for Server Certificate
6. cert_key.tar file downloads to PC then extract it
7. Import cert.pem to the macOS keychain

What did I miss?
 
Uncertain how I should import signing CA to browser? I had done the steps below:

1. Went to WAN DDNS page
2. Select Persistent Auto-generated
3. Select Generate a new certificate: YES and click Apply
4. Select Export for Server Certificate
6. cert_key.tar file downloads to PC then extract it
7. Import cert.pem to the macOS keychain

What did I miss?
Are steps 1 through 5 all just to get a copy of /tmp/mnt/ent/entware/var/cache/pixelserv/ca.crt?
Code:
# openssl11 x509 -text -noout -in /tmp/mnt/ent/entware/var/cache/pixelserv/ca.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ab:a9:d3:c4:4a:38:88:f8
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Pixelserv CA
        Validity
            Not Before: Mar 22 20:17:11 2019 GMT
            Not After : Mar 19 20:17:11 2029 GMT
        Subject: CN = Pixelserv CA
 
Are steps 1 through 5 all just to get a copy of /tmp/mnt/ent/entware/var/cache/pixelserv/ca.crt?
Code:
# openssl11 x509 -text -noout -in /tmp/mnt/ent/entware/var/cache/pixelserv/ca.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ab:a9:d3:c4:4a:38:88:f8
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Pixelserv CA
        Validity
            Not Before: Mar 22 20:17:11 2019 GMT
            Not After : Mar 19 20:17:11 2029 GMT
        Subject: CN = Pixelserv CA

Completely ignore me, tired and misread thinking it applied to my situation, which it doesn’t because I don’t run pixelserv. I shall now go take a nap :p
 
Completely ignore me, tired and misread thinking it applied to my situation, which it doesn’t because I don’t run pixelserv. I shall now go take a nap :p
Well it makes me consider:
  • If you did not have Samba and iCloud Drive, then steps 1 through 5 (6) would be a way to get the CA certificate to a client device
  • If you did not have Pixelserv-tls to create a certificate authority key pair and signing certificate, then you have done it some other way which requires more patience and/or software license cash than I have :)
 
Yesterday for the first time I had the problem you described with tls handshake going on forever and page wouldn’t load. It’s a new issue for me. 384.9. Refreshing browser and clearing cache had no effect but waiting a couple minutes it eventually unstuck itself and router GUI loaded back to login page.
Well, I am currently on 384.9; having just done the L&LD reset I'm sort of reluctant to jump to 384.10 just yet... Ordinarily I would dirty flash it and go on with life, but that would no doubt result in considerable forum side-eye. :p
Generating your own CA + certificate will resolve the issue. Why is the self-generated certificate causing issues with Chrome, I have no idea. I suspect Chrome is trying to do something to establish a chain of trust, and this causes Chrome itself to hang.

There was a similar issue with Firefox, resolved in 384.10 (you have to re-generate a new certificate however). It's a known bug in Firefox that was filed 3 years ago, and apparently the Firefox devs never fully fixed it...
Yep, I primarily use FF; I tried Chrome and had a similar issue. Did not try IE. I'll consider following the P-TLS cert how-to here this weekend.

Thanks all, for the considerable follow-up!
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top