ctw@aerospace.aero.org (Charles T. Wolverton) (05/27/90)
Would appreciate help with the following problem. The players: PCs running Hughes LAN Sys (nee Sytek) LINC/TCP v.2.03 (or maybe 2.02 - don't ask why I'm not sure!); Fibronics Spartacus TCP front-end for IBM 3090. Scene 1: FTP a 1420 byte file FROM a non-PS/2 AT TO the "IBM", i.e, the Spartacus; it works, but a SNIFFER dump shows two packets with the whole file - one without the FIN bit set, then an exact repeat except with the FIN bit set. Scene 2: FTP a short file, ~70 bytes FROM a PS/2-70 to the "IBM"; it works, but with the same double-packet feature. Scene 3: FTP the 1420 byte file from the PS/2-70; doesn't work; the PS/2 issues the STOR command, _then_repeats_it_immediately_; the "IBM" opens the data connection - it SYNs, the PS/2 SYN-ACKs, the IBM ACKs, and the PS/2 does _nothing_; after about 50 sec, the PS/2 does a RESET and the "IBM" closes the connection. Known bug?? Bad parameter settings?? Operator error?? Any ideas?? Thanks in advance. -charlie -- *** Charles T. Wolverton ***** Aerospace Corporation *** *** ctw@aerospace.aero.org ***** P.O. Box 92957 M1-023 *** *** (213) 336-5204 ***** Los Angeles, CA 90009 *** Newsgroups: Comp.protocols.tcp-ip.ibmpc Subject: FTP Problem: HLS PC/TCP-Spartacus Expires: References: Sender: Reply-To: ctw@aero.UUCP (Charles T. Wolverton) Followup-To: Distribution: usa Organization: The Aerospace Corporation, El Segundo, CA Keywords: Spartacus, PC/TCP, FTP Would appreciate help with the following problem. The players: PCs running Hughes LAN Sys (nee Sytek) LINC/TCP v.2.03 (or maybe 2.02 - don't ask why I'm not sure!); Fibronics Spartacus TCP front-end for IBM 3090. Scene 1: FTP a 1420 byte file FROM a non-PS/2 AT TO the "IBM", i.e, the Spartacus; it works, but a SNIFFER dump shows two packets with the whole file - one without the FIN bit set, then an exact repeat except with the FIN bit set. Scene 2: FTP a short file, ~70 bytes FROM a PS/2-70 to the "IBM"; it works, but with the same double-packet feature. Scene 3: FTP the 1420 byte file from the PS/2-70; doesn't work; the PS/2 issues the STOR command, _then_repeats_it_immediately_; the "IBM" opens the data connection - it SYNs, the PS/2 SYN-ACKs, the IBM ACKs, and the PS/2 does _nothing_; after about 50 sec, the PS/2 does a RESET and the "IBM" closes the connection. Known bug?? Bad parameter settings?? Operator error?? Any ideas?? Thanks in advance. -charlie Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: FTP Problem Expires: References: Sender: Reply-To: ctw@aero.UUCP (Charles T. Wolverton) Followup-To: Distribution: usa Organization: The Aerospace Corporation, El Segundo, CA Keywords: -- *** Charles T. Wolverton ***** Aerospace Corporation *** *** ctw@aerospace.aero.org ***** P.O. Box 92957 M1-023 *** *** (213) 336-5204 ***** Los Angeles, CA 90009 ***
EDMBV@NOBERGEN.BITNET (Bjoern Asle Valde) (05/28/90)
On Sat, 26 May 90 22:39:35 GMT Charles T. Wolverton said: >Would appreciate help with the following problem. >Keywords: Spartacus, PC/TCP, FTP > >The players: > >PCs running Hughes LAN Sys (nee Sytek) LINC/TCP v.2.03 (or maybe 2.02 >- don't ask why I'm not sure!); Fibronics Spartacus TCP front-end >for IBM 3090. I won't ask you why you don't know the version number for LINC/TCP, but you want to know anyway :-) LINC/TCP version 2.02 had all sorts of problems talking to ibm mainframes, they were gone in v. 2.03. pc/tcp (supplied directly from FTP Inc.) did not have these problems. Note: our site dosn't have the same connection (we use hyperchannel DX directly to an IO channel on the ibm side), but I would check out the LINC/TCP version anyway; it's much more simple than "Sniffer"ing..;-) Regards; Bjorn Asle Valde, Edb-Senteret, University of Bergen. "Time is an illusion; lunchtime doubble so" (Douglas Adams)
jbvb@VAX.FTP.COM (James Van Bokkelen) (05/29/90)
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
kzm@NMS.HLS.COM (Keith McCloghrie) (05/31/90)
> I suspect that Hughes 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. James is correct. Our 2.02 release incorporated FTP Software's 2.02 release, our 2.03 incorporates their 2.03. We've only recently received 2.04 from them, so it's not incorporated into our product at this time. We strongly recommend that you upgrade to 2.03. In this era of fast-paced advances in technology, any software which was written almost 3 years ago, starts to seem really creaky/cranky compared to today's. > 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). Yes, we call it the kernel, too. (We're not that imaginative !!). > 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. Yes, there's a known bug in the driver for the Western Digital MCA board (which I suspect you're running), which sometimes occurs when sending large packets. You can get the fix through contacting your local sales office. Keith McCloghrie Hughes LAN Systems