From owner-freebsd-net Fri Jun 26 08:10:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA22157 for freebsd-net-outgoing; Fri, 26 Jun 1998 08:10:44 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA22047 for ; Fri, 26 Jun 1998 08:10:04 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id XAA25215; Fri, 26 Jun 1998 23:08:45 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199806261508.XAA25215@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Open Systems Networking cc: freebsd-net@FreeBSD.ORG Subject: Re: aborted web connections ? In-reply-to: Your message of "Thu, 25 Jun 1998 23:14:49 -0400." Date: Fri, 26 Jun 1998 23:08:44 +0800 From: Peter Wemm Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Open Systems Networking wrote: > > > Ive noticed this several times now. I cant seem to figure out what causes > it cause im not logging with tcpdump. > But I have noticed that when I abort web conenctions sometimes it gets > wedged in a loop with whoever I was connecting to, and it winds up > creating a "flooding" action and totally nukes my poor ppp link. > It seems to happen with linux boxes. Ive included tcpdump output below. So > read on at your own risk. Is there anyway to "patch" this or a sysctl to > disable to keep this from happening its rather annoying. > This is a 3.0-current box BTW. I had this a couple of times on a 2.2-stable machine as well, but wasn't able to make much sense of it. It was on a front-line machine that really didn't need the link drain, so it was rebooted before I had much of a chance to look at it. :-( BTW, in the tcpdump, which IP address is yours? 206.252.171.10? Hmm. This looks different to what I've seen.. If I reduce the tcpdump a little, there doesn't appear to be anthing odd except for some missing lines... You have multiple TCP streams mixed together as well Session 1: 22:05:58.729163 them.http > you.4616: . 265064:266524(1460) ack 1 win 31744 22:05:58.927804 you.4616 > them.http: . ack 266524 win 17520 22:05:59.119064 them.http > you.4616: . 266524:267984(1460) ack 1 win 31744 22:05:59.127815 you.4616 > them.http: . ack 267984 win 17520 22:05:59.348774 them.http > you.4616: P 267984:268876(892) ack 1 win 31744 [appears to have soem sequence space missing here, the seq jumps ~10KB ] 22:06:02.127722 you.4616 > them.http: . ack 278528 win 17520 22:06:03.379003 them.http > you.4616: . 278528:279988(1460) ack 1 win 31744 22:06:03.527637 you.4616 > them.http: . ack 279988 win 17520 22:06:03.768710 them.http > you.4616: . 279988:281448(1460) ack 1 win 31744 22:06:03.927615 you.4616 > them.http: . ack 281448 win 17520 This looks like a typical HTTP connection to me, possibly crossing a write() boundary on the server with the automatic PSH. Otherwise it's a persistant http connection. Session 2: 22:06:02.298999 them.http > you.4617: . 131072:132532(1460) ack 1 win 31744 22:06:02.327750 you.4617 > them.http: . ack 132532 win 17520 22:06:02.658828 them.http > you.4617: . 132532:133992(1460) ack 1 win 31744 22:06:02.727653 you.4617 > them.http: . ack 133992 win 17520 22:06:02.988706 them.http > you.4617: . 133992:135452(1460) ack 1 win 31744 22:06:03.127658 you.4617 > them.http: . ack 135452 win 17520 22:06:04..927575 you.4617 > them.http: . ack 136912 win 17520 ^^ what's this? There is another sequence space gap here. 22:06:04.908681 them.http > you.4617: . 135452:136912(1460) ack 1 win 31744 This looks like a conventional HTTP download. Session 3: 22:06:04.128768 them.http > you.4619: . 252493:253953(1460) ack 0 win 31744 22:06:04.327623 you.4619 > them.http: . ack 253953 win 17520 22:06:04.518920 them.http > you.4619: . 253953:255413(1460) ack 0 win 31744 22:06:04.527618 you.4619 > them.http: . ack 255413 win 17520 22:06:05.268844 them.http > you.4619: . 255413:256873(1460) ack 0 win 31744 22:06:05.327661 you.4619 > them.http: . ack 256873 win 17520 22:06:05.658729 them.http > you.4619: . 256873:258333(1460) ack 0 win 31744 22:06:05.727579 you.4619 > them.http: . ack 258333 win 17520 22:06:06.018713 them.http > you.4619: . 258333:259793(1460) ack 0 win 31744 22:06:06.127535 you.4619 > them.http: . ack 259793 win 17520 22:06:06.268623 them.http > you.4619: P 259793:260685(892) ack 0 win 31744 22:06:06.327537 you.4619 > them.http: . ack 260685 win 17520 22:06:06.658673 them.http > you.4619: . 260685:262145(1460) ack 0 win 31744 22:06:06.727562 you.4619 > them.http: . ack 262145 win 17520 22:06:07.020933 them.http > you.4619: . 262145:263605(1460) ack 0 win 31744 22:06:07.127501 you.4619 > them.http: . ack 263605 win 17520 22:06:07.408738 them.http > you.4619: . 263605:265065(1460) ack 0 win 31744 22:06:07.527490 you.4619 > them.http: . ack 265065 win 17520 22:06:07.768567 them.http > you.4619: . 265065:266525(1460) ack 0 win 31744 22:06:07.927486 you.4619 > them.http: . ack 266525 win 17520 Also looks like a conventional HTTP download. I note that the 'them' IP address is: www.scl.ameslab.gov. You're not by any chance trying to view some page that's got a HTTP REFRESH tag or something else to cause your browser to reload faster than you can download? Perhaps a self refreshing status page or something? It looks basically like you're simply downloading gobs of data in parallel. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message