|
On 17.02.2019 1:52, ghe wrote:
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: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. 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. 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).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. You have to use "sendwait" parameter set to at least 1 (second), to gather reliable information with "traceroute" command. For the situation you described the most possible cause is a packet loss on top of a "generous" T1 connection.'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? 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 ⠈⠳⣄⠀⠀⠀⠀ |