Date: Sun, 27 Jul 1997 15:25:26 -0600 (MDT) From: Marc Slemko <marcs@znep.com> To: Bill Fenner <fenner@parc.xerox.com> Cc: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, FreeBSD-current <current@freebsd.org> Subject: Re: Another 'fetch' reset by peer: -b NOT work for this site... Message-ID: <Pine.BSF.3.95.970727151433.26104G-100000@alive.znep.com> In-Reply-To: <97Jul27.140325pdt.177512@crevenia.parc.xerox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970727151433.26104G-100000>