Path: utzoo!attcan!uunet!samsung!usc!ucsd!ucbvax!VAX.FTP.COM!jbvb
From: jbvb@VAX.FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: FTP PUT from PC causes reset
Message-ID: <9008081339.AA13504@vax.ftp.com>
Date: 8 Aug 90 13:39:09 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@vax.ftp.com
Organization: The Internet
Lines: 21


    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