At first I thought this was a FireFox specific problem, but I'm also seeing this with Chrome and Midori. After a reboot the browsers work fine for a while, but eventually the TLS handshakes slow to a crawl (30+ seconds). Since this doesn't seem to be browser specific I'm wondering if this is a Debian and/or SparkyLinux issue. Has anyone encountered this and found a fix?
Pretty difficult to help when important info is not given. Sparky 4 or 5? Did you apt-mark hold libgnutls30 during the hiccup. Firefox or Firefox-esr Chrome or Chromium. Mark up as code output your chrome... and firefox... versions and if possible also any pertinent logs - example (Use the # button)
aptitude show firefox-esr
Package: firefox-esr
Version: 60.7.1esr-1~deb9u1
State: installed
Automatically installed: no
Priority: optional
Vpn ?? Can you isolate it to one machine or could it be in the kit you have from your isp?
I do not know if the problems would show up if run in terminal, but it might. So example of starting up a browser in a terminal.
paxmark@raunes:~$ chromium
ATTENTION: default value of option force_s3tc_enable overridden by environment.
FireFox 67.0.4 (as indicated by Pavroo in FF thread)
Chrome-stable 75.0.3770.100-1
Sparky 5.7
VPN not used.
Why would a terminal start be useful? The problem occurs during a TLS handshake - not before.
Because STDOUT (including debug and error messages) will be visible in the terminal.
Quote from: dbarron on June 25, 2019, 10:04:21 PM
Because STDOUT (including debug and error messages) will be visible in the terminal.
/var/log/