Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!decwrl!mogul
From: mogul@decwrl.dec.com (Jeffrey Mogul)
Newsgroups: comp.unix.ultrix
Subject: Re: Ultrix 2.x ADB patch to TCP/IP TTL (was Re: Problem with TCP/IP connection to remote sites)
Message-ID: <278@jove.dec.com>
Date: 6 Feb 90 00:11:35 GMT
References: <276@jove.dec.com> <303@cfa.HARVARD.EDU>
Distribution: usa
Organization: DEC Western Research
Lines: 21

In article <303@cfa.HARVARD.EDU> wyatt@cfa.HARVARD.EDU (Bill Wyatt) writes:
>Well, if this is the original poster's problem, we also had the same
>problem and unfortunately, we're still on Ultrix 2.x for yet a little
>while longer (don't ask). A few months ago we stopped being able to
>reach some remote sites, with the symptoms described.  We do have
>source, so I grovelled around for a while, looking at assembler output
>and the like, and found the location of the TTL parameter to fix. I
>hereby post it with no guarantees (except that we've used it for
>several months with no problem). 

I can't comment directly on the correctness of your fix, since I
don't have an Ultrix 2.2 system to test it on, but I should point
out that the TTL parameter also occurs in the code in the tcp_respod()
function in tcp_subr.c.  I suspect that what this means is that if
you have the wrong TTL here, some subset of your ACK packets will
get dropped.  If things are working for you, either it's because I'm
wrong about this, or it's because almost all TCP connections have data
flowing in both directions (and your fix should set the TTL right for
any segment carrying data).

-Jeff