Date: Thu, 20 May 2004 13:18:03 -0700 From: Ulf Zimmermann <ulf@Alameda.net> To: Dan Nelson <dnelson@allantgroup.com> Cc: Ulf Zimmermann <ulf@Alameda.net> Subject: Re: Problem with a 5.2.1 system and downloading Message-ID: <20040520201802.GJ58545@seven.alameda.net> In-Reply-To: <20040520195924.GB19455@dan.emsphone.com> References: <20040520194027.GH58545@seven.alameda.net> <20040520195924.GB19455@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 20, 2004 at 02:59:24PM -0500, Dan Nelson wrote: > In the last episode (May 20), Ulf Zimmermann said: > > I got in my office two machines. One works fine, the other doesn't. > > Office has a Netscreen-10 as firewall which connects then to a Cisco > > with a T1 Frame Relay to the Internet. > > > > One machine is 4.9-REL and it works like a charm. The other is a > > 5.2.1-REL (cvsup'ed to latest today). It has a single CPU, PAE kernel > > (6GB memory). This 5 machine hangs often at different spots during > > fetch for ports. > > > > Today I captured the tcp connections and here is what it shows: > > > > Initial TCP setup: > > > > 12:26:25.895246 10.1.42.42.49190 > 128.125.253.59.80: S 3565497776:3565497776(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 88945 0> (DF) > > 12:26:25.919572 128.125.253.59.80 > 10.1.42.42.49190: S 1889662716:1889662716(0) ack 3565497777 win 5840 <mss 1460,nop,wscale 0> (DF) > > 12:26:25.919592 10.1.42.42.49190 > 128.125.253.59.80: . ack 1 win 32850 (DF) > > > > Here are the last 4 packets back and forth going correctly: > > > > 12:26:29.052678 128.125.253.59.80 > 10.1.42.42.49190: . 487518:488978(1460) ack 194 win 5840 (DF) > > 12:26:29.052689 10.1.42.42.49190 > 128.125.253.59.80: . ack 424738 win 32850 (DF) > > 12:26:29.060577 128.125.253.59.80 > 10.1.42.42.49190: . 488978:490438(1460) ack 194 win 5840 (DF) > > 12:26:29.060589 10.1.42.42.49190 > 128.125.253.59.80: . ack 424738 win 32850 (DF) > > > > And now the last data packet comes in: > > > > 12:26:29.069061 128.125.253.59.80 > 10.1.42.42.49190: . 424738:426198(1460) ack 194 win 5840 (DF) > > > > And now look at the ack: > > > > 12:26:29.069087 10.1.42.42.49190 > 128.125.253.59.80: . ack 490438 win 0 (DF) > > 12:26:29.069250 10.1.42.42.49190 > 128.125.253.59.80: . ack 490438 win 1790 (DF) > > 12:26:29.069342 10.1.42.42.49190 > 128.125.253.59.80: . ack 490438 win 3326 (DF) > > Looks reasonable. Note the last two acks you pasted were acking data > pretty early in the window. The remote end finally resends that > packet, and your server bumps the ack point up to the last byte it > received. The client process hasn't had a change to empty the socket > buffer yet, though, so the window slams shut. > > > 12:26:29.069461 10.1.42.42.49190 > 128.125.253.59.80: . ack 490438 win 4862 (DF) > ... > > 12:26:29.070155 10.1.42.42.49190 > 128.125.253.59.80: . ack 490438 win 32510 (DF) > > The client process has read all its data and the window opens up. The > server isn't sending any more packets for some reason, though. > > > So does this look normal to anyone ? > > Your end looks fine. Once your system started sending acks with a > nonzero window, the remote end should have started sending more data. > > -- > Dan Nelson > dnelson@allantgroup.com I only got the problems with sites where I go through the netscreen. Fetching the same files via the 4.9 box, everything works. Looking at the full dump, my 5 box never really has to catch up (most of the time its one data packet, one ack), which is why the change from "win 32850" to "win 0" (and then climbing) looks strange to me. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040520201802.GJ58545>