A01DGU1@NIUCS.BITNET (Dave Ulrick) (08/02/90)
I'm having a problem getting IBM VM TCP/IP 1.2.2 (or "FAL") to talk
properly with some PCs that we have. The PCs are running FTP Software's
PC/TCP. When the PC user tries to do an FTP PUT of either an ASCII or
binary file, FAL's FTP server sends the PC two resets. The PC then hangs,
and has to be rebooted. Of course, this "response" on the part of
the FTP client is not very desirable. Nonetheless, we would like to
determine why VM's FTP server doesn't like the packets that the PC is
sending him.
Basically, our configuration is something like this:
VM host <--> BTI ELC <--> Proteon router <--> LAN server <--> PC
Our networking person here tells me that the router is apparently taking
the packets being sent by the PC and is breaking them down into 512-byte
packets. The packets are then being sent on to VM TCP/IP, who is
complaining about them. The following is the GATEWAY statement from
VM's PROFILE TCPIP:
GATEWAY
* Network First hop Driver Packet size Subnet mask Subnet value
131.156 = ETH1 1500 0.0.255.0 0
DEFAULTNET 131.156.4.2 ETH1 DEFAULTSIZE 0
Any ideas on what I can do to convince the VM and PC TCP/IP to cooperate?
Our networking person has already talked with FTP Software; they seem to
feel that FAL is inproperly handling the shortened 512 byte packets.
We're running FAL under VM/SP 5.0 with the Lippke BTI driver.
Thanks,
Dave
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Ulrick Bitnet: A01DGU1@NIUCS
Northern Illinois University Internet: A01DGU1@VM.NIU.EDU
DeKalb, IL, USAjbvb@VAX.FTP.COM ("James B. Van Bokkelen") (08/08/90)
From: Doug Nelson <08071TCP%MSU@pucc.princeton.edu>
I haven't yet had a chance to check this against 1.2.2, but I know I saw
this problem under 1.2.1, and no gateway was involved here. FTP SW is
setting the type of service field to all ones, which is my guess for the
real problem. So when FAL opens the data connection with TOS=0, and
PC/TCP responds with TOS=FF, FAL is evidently ignoring the response
completely, rather than just ignoring the TOS value.
Doug - As we ship it, the only application in 2.04 that sets the IP
TOS to anything other than 0 (the default) is SETCLOCK.EXE (which I
did to prove it could be done, before the official list of TOS values
in RFC 1060 was available). I just checked an FTP transfer here, and
the TOS was 0 all the way through. If you see it on your net, you
might check to see that the built version of SRCLIB\TCP matches
SRCLIB\INTERNET - if the TCP predates the addition of the TOS argument
to in_write(), then garbage is getting pulled off the stack...
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901