cxf@ritcv.UUCP (Charles Fung) (05/26/88)
We have noticed a problem with tcp/ip communication between ULTRIX
systems and AT&T 3B2's. I wonder if anybody can help.
Here at Rochester Institute of Technology, we have some Vax's running
ULTRIX and a bunch of AT&T 3B2's. We noticed that "ftp" and "telnet"
and also email fowarding (from VMS-land thru' ULTRIX systems to the
AT&T machines) is extremely unreliable. Finally was forced to confront
the problem (users shouting "we want mail" outside our office - something
like that).
Problems:
(1) With "ftp", it doesn't matter whether the "ftp" process is initiated
from either end (ULTRIX/ATT). If the file is to be transferred from
the ULTRIX system to the AT&T system, it fails. The other direction
works fine.
(2) "telnet" sessions just hangs as soon as you do a cat on the passwd
file. This only happens when you are telnet'ing to a ULTRIX site
from a AT&T host.
(3) Email coming in to a ULTRIX system that are to be forwarded to a
AT&T host sits around in the mqueue forever (the sendmail daemon
wakes up every half hr and delivers a copy, with only the header,
to the receipient - thereby flooding the his/her mailbox until
somebody got notified and goes into the mqueue and blow away the
queued up files). Short mail messages can make it through though.
What we found:
Putting sendmail in verbose mode shows that there is a read error on
the ULTRIX side after the SMTP agents has done the necessary handshake
(ie, at the time when the data portion of the mail is to be transferred).
Using a SUN3 on the network, we ran "etherfind" to monitor the packets
being thrown at one another between the ULTRIX and AT&T systems. It
shows, as soon as the sendmail daemon on the ULTRIX side start sending
the body of the mail message, that tcp packets of length 1082 are
continuously being sent to the AT&T system. But it's a one way trip.
The AT&T system never ACK'ed. Of course, after a while the ULTRIX side
gives up.
Next, we tried "ftp" and found the same thing. Tcp packets of length
1082 being thrown at the AT&T system and the latter just sit there.
It works fine if the file is small. So we tried reversing the direction
of the ftp to see what size is used when the AT&T system throws tcp
packets at the ULTRIX machine. It turned out to be 1080 and everybody
is happy (file got transferred with no problems). Just for the fun of
it, we tried BSD4.3 and they use 1078.
Now, I don't really know what unit "etherfind" uses to report the
"length" of the packets, but it seems to me that it's the AT&T systems
that's having a hard time dealing with tcp packets larger than what
the phone company consider appropriate. The rest of other systems
talk to the ULTRIX systems with no problems (BSD, MASSCOMP/RTU, APOLLO).
QUESTION:
Has anybody out there experienced similar problems? Any fixes?
Is there some way of changing the packet size used by tcp/ip
(on either the UULTRIX machines or on the AT&T machines - I don't
care, I just want them to talk to one another).
Thank you much.
Charles Fung
Systems Analyst
Rochester Institute of Technology
Rochester NY
allegra!moss!rutgers!rochester!ritcv!cxf (UUCP)
cxf@rit (CSNET)
cxf@CS.RIT.EDU (MILNET)