IP connect to certain host times out

Help
1

A couple of hours ago, connections to my email host no longer went through - from Haiku and NetBSD, a couple different computers and revs. No upgrades or configuration changes, just stopped working, so I’m thinking there must have been some change on the other end.

DNS lookup goes OK. There will eventually be SSL protocol after the socket connection, but I don’t get to that point. Same code still works on on Linux, MacOS.

Is there some kind of new and improved TCP/IP protocol that they might have swapped in, at the hosting provider, that my Haiku implementation might be missing? I guess there’s someone at that address, because ping works, but from Haiku and NetBSD I can’t establish a connection to port 993. Times out.

2

Still wrestling with this, and one of the support staff on the hosting end apparently took my use of Haiku seriously enough to do a little research (?), and according to him, “From what I can google, it’s … a built-in firewall on Haiku.”

Is it? Haiku has any kind of firewall, blacklist, anything?

I don’t find the reasoning very compelling, anyway. The exact same problem occurs on my NetBSD install that had been sitting unused for months, and it seems a pretty unlikely coincidence. But understandably they don’t have much to go on – every other OS connects fine, everything look OK there, etc. On Haiku, there’s just one packet that goes out to the remote host, and nothing ever comes back. Same on NetBSD, except that it retries periodically. If it’s a router along the way, including my fiber router, it would have to be blocking traffic with some knowledge of the OS it came from, and the successful and unsuccessful packets seem pretty similar to my eye.

3

No, Haiku has no firewalls.

4

For my understanding, your e-mail server is a hosted thing? or is this a vps?

What does DNS Say? Do you have an A record or only a AAAA? Haiku cannot easily use ipv6 for example, but ipv4 works.

Is the problem with IMAP or with SMTP or with both?

What software are you using on Haiku? mail_daemon? If so you ca stop the normal mail_daemon with launch_roster and launch it in terminal to get log output (yes, convoluted, sorry :confused: )

5

Well, none of the above, really. This a fairly typical wifi-fiber router scenario, with several clients here in the house. Haiku on two of them, one of those two also NetBSD and Linux. All of these can connect to every IP address in the known universe, except Haiku and NetBSD can’t connect to this one host. I don’t believe the host is accessible via ipv6 even if I wanted to.

connect() sends one packet, gets no response. No network client can get anywhere that way. Mail, web browser, whatever. I use my own program for email, WebPositive for web (it’s also a web site), but it doesn’t matter. I check to see that it’s still broken with a C program that just calls connect(), usually to port 80. The web site, by the way, is https://yorkmaster.org, an archive of a Danish musician’s online music and images.

The only thing that makes any sense in this diagram, is that there’s something about that packet we’re sending, that makes a difference somewhere down the line, probably at the remote host since it’s the only place that has the problem.

6

Can you ping this host from the affected machines ?

If not, try changing the ping packet size, and see if under some sizes it works. That would point to some problem /incompatibility with the MTU sizes used by the router or maybe set by the network adapter driver.

7

ping, traceroute go OK. 0% packet loss with ping, ordinary elapsed times.

(Well, traceroute shows some high “loss” rates along the way, but that seems to be normal.)

8

I guess a tcpdump capture on your netbsd and another tcpdump capture made doing the same connection from Linux, and then compare the content of the connection establishment packets could help to figure why this specific host do accept the connection or not.

Tcpdump or white shark, as you want
The idea is to compare the exact content of the first N packets from your netbsd vs linux

I don’t refer haiku because I’m not sure tcpdump is available on haiku.

9 
Haiku 04:12:10.425992 IP 192.168.1.81.40117 > 70.32.23.114.80: Flags [S], seq 720651621, win 255, options [mss 1460,sackOK,TS val 11530425 ecr 0,nop,wscale 8], length 0

NetBSD 10:03:05.543884 IP 192.168.1.81.65534 > 70.32.23.114.80: Flags [S], seq 3877119505, win 32768, options [mss 1460,nop,wscale 3,sackOK,TS val 1 ecr 0], length 0
NetBSD 10:03:11.541410 IP 192.168.1.81.65534 > 70.32.23.114.80: Flags [S], seq 3877119505, win 32768, options [mss 1460,nop,wscale 3,sackOK,TS val 13 ecr 0], length 0
NetBSD 10:03:23.541399 IP 192.168.1.81.65534 > 70.32.23.114.80: Flags [S], seq 3877119505, win 32768, options [mss 1460,nop,wscale 3,sackOK,TS val 37 ecr 0], length 0

MacOS 21:00:44.018478 IP 192.168.1.72.51815 > 70.32.23.114.80: Flags [SEW], seq 2600447463, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 885938618 ecr 0,sackOK,eol], length 0
MacOS 21:00:45.019680 IP 192.168.1.72.51815 > 70.32.23.114.80: Flags [S], seq 2600447463, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 885939618 ecr 0,sackOK,eol], length 0
MacOS 21:00:46.020814 IP 192.168.1.72.51815 > 70.32.23.114.80: Flags [S], seq 2600447463, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 885940619 ecr 0,sackOK,eol], length 0
MacOS 21:00:46.128542 IP 70.32.23.114.80 > 192.168.1.72.51815: Flags [S.], seq 2899772825, ack 2600447464, win 28480, options [mss 1412,sackOK,TS val 312618450 ecr 885940619,nop,wscale 7], length 0
MacOS 21:00:46.128666 IP 192.168.1.72.51815 > 70.32.23.114.80: Flags [.], ack 1, win 4112, options [nop,nop,TS val 885940726 ecr 312618450], length 0
MacOS 21:00:46.129001 IP 192.168.1.72.51815 > 70.32.23.114.80: Flags [F.], seq 1, ack 1, win 4112, options [nop,nop,TS val 885940726 ecr 312618450], length 0
MacOS 21:00:46.236316 IP 70.32.23.114.80 > 192.168.1.72.51815: Flags [F.], seq 1, ack 2, win 223, options [nop,nop,TS val 312618558 ecr 885940726], length 0
MacOS 21:00:46.236393 IP 192.168.1.72.51815 > 70.32.23.114.80: Flags [.], ack 2, win 4112, options [nop,nop,TS val 885940833 ecr 312618558], length 0
10

Well, the most visible difference seems to be in:

  • lack of multiple resend of the TCP SYN packet on Haiku
  • long delay between the retries on NetBSD
  • while on macos the retries of TCP SYN are every second, finally getting an ACK, but after 3s

This plus your statement that you can see high loss rate in trace route for this remote host could be leading to bad network routing that only a more insisting TCP/ip stack succeed to finally overcome.

Maybe the TCP stacks on haiku and netbsd are not trying enough often the TCP SYN retries, seems lire as they do retries as for other TCP packets.

Didn’t knew that tcpdump was available on Haiku …

11

That seemed worth a try, so I hacked up TCP:

Haiku 00:07:02.785373 IP 192.168.1.81.40016 > 70.32.23.114.80: Flags [S], seq 26424081, win 255, options [mss 1460,sackOK,TS val 422785 ecr 0,nop,wscale 8], length 0
Haiku 00:07:03.785945 IP 192.168.1.81.40016 > 70.32.23.114.80: Flags [S], seq 26424081, win 255, options [mss 1460,sackOK,TS val 423785 ecr 0,nop,wscale 8], length 0
Haiku 00:07:04.786488 IP 192.168.1.81.40016 > 70.32.23.114.80: Flags [S], seq 26424081, win 255, options [mss 1460,sackOK,TS val 424786 ecr 0,nop,wscale 8], length 0
Haiku 00:07:04.894716 IP 70.32.23.114.80 > 192.168.1.81.40016: Flags [S.], seq 154626324, ack 26424082, win 28480, options [mss 1412,sackOK,TS val 3339483294 ecr 424786,nop,wscale 7], length 0
Haiku 00:07:04.894821 IP 192.168.1.81.40016 > 70.32.23.114.80: Flags [.], ack 1, win 255, options [nop,nop,TS val 424894 ecr 3339483294], length 0
Haiku 00:07:04.895166 IP 192.168.1.81.40016 > 70.32.23.114.80: Flags [F.], seq 1, ack 1, win 255, options [nop,nop,TS val 424895 ecr 3339483294], length 0
Haiku 00:07:05.003263 IP 70.32.23.114.80 > 192.168.1.81.40016: Flags [F.], seq 1, ack 2, win 223, options [nop,nop,TS val 3339483402 ecr 424895], length 0
Haiku 00:07:05.003318 IP 192.168.1.81.40016 > 70.32.23.114.80: Flags [.], ack 2, win 255, options [nop,nop,TS val 425003 ecr 3339483402], length 0

You may note that this time, I got a reply! So I think you may be on to something here. I also verified that WebPositive could connect to the website.

Thanks for the idea!