From owner-freebsd-current Sun Jul 27 14:23:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA22249 for current-outgoing; Sun, 27 Jul 1997 14:23:45 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA22244 for ; Sun, 27 Jul 1997 14:23:43 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id PAA14342; Sun, 27 Jul 1997 15:23:35 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id PAA27861; Sun, 27 Jul 1997 15:25:26 -0600 (MDT) Date: Sun, 27 Jul 1997 15:25:26 -0600 (MDT) From: Marc Slemko To: Bill Fenner cc: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= , Garrett Wollman , FreeBSD-current Subject: Re: Another 'fetch' reset by peer: -b NOT work for this site... In-Reply-To: <97Jul27.140325pdt.177512@crevenia.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 27 Jul 1997, Bill Fenner wrote: > As far as I can tell, Marc's patch and the "-b" flag *should* do the > same thing -- if you don't give the MSG_EOF flag to sendmsg(), it > will not set the FIN bit on the first data packet. > > The only difference is that explicitly using connect(), it won't send > data with the first packet. RFC793 section 3.9 explicitly allows data > with a SYN. And, due to this fact, it won't send a FIN in response to the other end's SYN. Either one of these two things could be what is causing problems on the remote system. This particular problem is not caused by the early half-close that -b works around. Even though sending data with the SYN is permitted by the RFC, the fact is that there are too many broken boxes out there that don't work right with it. It could be viewed as an argument for disabling T/TCP (and the sending of data in the SYN) on your machine entirely or for allowing the few applications which do make such calls to disable it. I don't really have any preference either way. It could also be viewed as an argument for giving up and making the changes to fetch so it is less efficient and doesn't cause problems like ftp and lynx, but I don't think I would go for that. Some of the systems which I noticed being broken in this way were SunOS 4.x systems, but not all SunOS 4.x systems behave like that.