From owner-freebsd-current  Sat Jul 26 17:02:20 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id RAA26278
          for current-outgoing; Sat, 26 Jul 1997 17:02:20 -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 RAA26259;
          Sat, 26 Jul 1997 17:02:14 -0700 (PDT)
Received: from znep.com (uucp@localhost)
	by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id SAA21647;
	Sat, 26 Jul 1997 18:02:09 -0600 (MDT)
Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id SAA21946; Sat, 26 Jul 1997 18:04:02 -0600 (MDT)
Date: Sat, 26 Jul 1997 18:04:01 -0600 (MDT)
From: Marc Slemko <marcs@znep.com>
To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
cc: wollman@FreeBSD.ORG, FreeBSD-current <current@FreeBSD.ORG>
Subject: Re: Another 'fetch' reset by peer: -b NOT work for this site...
In-Reply-To: <Pine.BSF.3.96.970727025716.3200A-100000@lsd.relcom.eu.net>
Message-ID: <Pine.BSF.3.95.970726175737.19606K-100000@alive.znep.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id RAA26261
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Sun, 27 Jul 1997, [KOI8-R] Андрей Чернов wrote:

> fetch http://www.geocities.com/Tokyo/Temple/2761/menu1.gif
> fetch: reading reply from www.geocities.com: Connection reset by peer
> 
> adding -b option gives _the_same_ result.
> 
> BTW, new ftp and lynx work nice for this one too.
> Please fix (another -b-like option?)

marcs@valis:~$ fetch http://www.geocities.com/Tokyo/Temple/2761/menu1.gif
fetch: reading reply from www.geocities.com: Connection reset by peer
marcs@valis:~$ sudo sysctl -w net.inet.tcp.rfc1644=0
net.inet.tcp.rfc1644: 1 -> 0
marcs@valis:~$ fetch http://www.geocities.com/Tokyo/Temple/2761/menu1.gif
Receiving menu1.gif (15874 bytes): 100%
15874 bytes transfered in 0.2 seconds  (81.36 kB/s)

You would need an option to change the way the fetch code handles the 
connect so FreeBSD doesn't try to use T/TCP.  You may want to ask 
Geocities what OS their server is running on to see if it one with
known braindead T/TCP activity or not.

18:00:43.330713 valis.worldgate.com.tr-rsrb-p2 > 205.180.58.12.http: SP 1382936415:1382936515(100) win 16464 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF)
18:00:43.382215 205.180.58.12.http > valis.worldgate.com.tr-rsrb-p2: S 1234567:1234567(0) ack 1382936416 win 2048
18:00:43.382867 valis.worldgate.com.tr-rsrb-p2 > 205.180.58.12.http: FP 101:155(54) ack 1 win 16464 (DF)
18:00:43.433453 205.180.58.12.http > valis.worldgate.com.tr-rsrb-p2: R 1:1(0) ack 102 win 2048

My guess would be that the other side isn't expecting to see a FIN in
the packet in response to its SYN, but it could be a bogon in FreeBSD's
code...