Path: utzoo!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!VAX.FTP.COM!jbvb
From: jbvb@VAX.FTP.COM (James Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: FTP Problem: PS/2-to-Spartacus
Message-ID: <9005291405.AA01736@vax.ftp.com>
Date: 29 May 90 14:05:06 GMT
Article-I.D.: vax.9005291405.AA01736
References: <74129@aerospace.AERO.ORG>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 38

Bjorn Valde is correct as far as he goes, here is a little more info:

I suspect that Huges (Sytek) version numbers map 1:1 to ours, thus
2.02 was current q2 1988 to q4 1988, 2.03 from q4 1988 to q4 1989, and
2.04 from q4 1989 to the present.  If they lag behind us a quarter or
so it isn't their fault - the kit they get isn't ready to go when we
start shipping ourselves.

Sending the FIN bit with a retransmission of the last unacknowleged
data packet is a characteristic of our TCP, which assumes that the
cost per packet is much greater than the cost per byte.

Your "Scene 3", where the STOR command is repeated immediately, looks
like it could be a problem with the hardware driver, depending on the
definition of "immediately".  If the interval is a matter of a few
milliseconds and the other end didn't send any packets that could have
provoked it, the hardware driver reported an error on the first send.

You don't say what is happening to the TCP window on the data
connection, but IBM mainframes tend to offer very large values, and
change them in arbitrary ways.  This could be what is confusing the
TCP, in which case you need an upgrade to the TCP/IP TSR module
(I don't know what Hughes calls it - we call it the kernel).

Alternatively, the large data packet we send could be confusing the
PS/2's hardware driver, and when we get repeated errors we give up.
If so, you should be able to use the "-l" argument to PING, or try to
FTP files of various sizes between 70 and 1420, and discover the
packet length that breaks (the cause will probably be the Huges board
driver, not the TCP/IP resident module).  Upgrading to Huges latest
should help, as could trying to get the mainframe configured to use a
smaller TCP Maximum Segment Size value.  The reason this probably
doesn't happen with Unix boxes is that they never offer a TCP MSS
greater than 1024, which means that many hardware driver authors don't
test full-size packets much.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901