[comp.unix.ultrix] Problem with TCP/IP connection to remote sites

mogul@decwrl.dec.com (Jeffrey Mogul) (02/02/90)

In article <6227@cps3xx.UUCP> nanda@cpsvax.cps.msu.edu (Arun Nanda {manager}) writes:
>We are a VAX 8600 site running Ultrix 2.2.  Of late, I have observed a
>strange symptom that I know, for sure, was not existing before.  The
>problem is as follows:
>
>While trying to establish connections to certain remote sites through
>"telnet", "rlogin" or "ftp", the command always fails with the
>connection timing out.  This also happens with SMTP connections from the
>mail server.  Some example sites with which the connection fails are
>relay.cs.net, think.com etc.  However, executing a "ping" on these sites
>always succeeds indicating they are alive.

This sounds to me like your TCP datagrams are being sent with a TTL
(Time to live in the IP header) that is too small.  The problem may
have arisen recently because your route to these "certain hosts"
has changed, from one with a short path to one with a longer path.

Ultrix 2.2 inherited from 4.2BSD an initial TTL of 15 for TCP packets.
This was large enough back when 4.2BSD first came out, but the "diameter"
of the Internet has since grown to be greater than 15 hops.  For example,
from decwrl.dec.com to your host cpsvax.cps.msu.edu is 14 hops; you
can discover this by using the "traceroute" command that is floating
around in the public domain.  Since decwrl.dec.com is fairly close
to the core of the Internet, I suspect that there are many sites
further away from you than that.

Ping works when TCP doesn't, because the ping program sets a larger TTL.

In Ultrix 3.0, the TCP TTL is set to 60, which is probably large enough.
If you are able to upgrade to the latest release of Ultrix, you will
probably solve this particular problem, and get better TCP performance
in general.

Otherwise, if you have an Ultrix source license, you can change the
value of TCP_TTL in netinet/tcp_timer.h, and recompile.  If you don't
have sources, in theory it should be possible to patch your kernel to use
a larger TTL.  I would rather not guess the addresses to patch, though!

-Jeff