Web lists-archives.com

Re: web problem




On 17.02.2019 1:52, ghe wrote:
Buster, Firefox 60.5.0esr, T1 connection

It seems...

...that the SSL/TLS handshake is taking too long -- at most sites.
Google, Debian, Cisco, Amazon and some others work fine. DuckDuckGo does
not. The Python docs at New Mexico Tech doesn't.

SMTP and SSH bidirectional and FTP from my server are OK.

Firefox, and other browsers, time out.

The web server in the next room is great on http, but there's a home
made cert for https, and Firefox times out trying to get to the https at
Mozilla so I can tell it it's OK. So I can't check my site's SSL handshake.
If you can access your http server via private ip (e.g. 192.168.0.10) and use VHosts, you can test https connections to it by editing your "/etc/hosts" file and adding:
    192.168.0.10    www.myservername.com
By doing this you will trick your browser to access your site by fqdn "www.myservername.com" but with private ip.
After testing just revert changes back.

When I ping something (default 1 sec TTL) for a long time on the T1,
there are a few 'holes.' I've never seen that before. Traceroute also
has holes, but that's to be expected, and it finishes eventually.
By default "traceroute" command uses 0ms delay between requests. For the majority of ISPs this behavior is considered as flood and will be rate-limited (dropped).
You have to use "sendwait" parameter set to at least 1 (second), to gather reliable information with "traceroute" command.

'telnet <host> 25|80|443' seems to be OK. So does a reasonable ping.

The T1 has been solid as a rock for years. It happens with all the boxes
around the apartment. When I use one of the WiFi nets (2) here, they
work fine.

It's just that SSL handshake. It's possible that there are holes in the
TCP (I assume) handshake?

Anybody experienced this? Or know what I can do about it?

For the situation you described the most possible cause is a packet loss on top of a "generous" T1 connection.
The tcp/ip protocol is stateful by nature (it cares about packets consistency and reliability of send-receive operations), so if some packets got lost or become corrupted during send-receive exchange they have to be send again. Eventually all data will be sent and delivered, but at the cost of time.
To diagnose this problem you have to check the whole chain from your PC's network adapter and cables (or air in case of wireless connection :) ), your network switches, routers, firewalls and after that talk to your ISP about this problem, because they can see if there is a problem with their ISDN network, or if these problems coming from another ISP up the chain all the way to the final host you have problem with.

A simple way to check if your network has problems is by using "iperf3" program. It helps to saturate the connection between 2 hosts and check for possible packet loss (column called "Retr" should be 0 at all times).

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀