From owner-freebsd-hackers@FreeBSD.ORG Thu May 20 12:59:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54FA016A4CE for ; Thu, 20 May 2004 12:59:35 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA4E243D4C for ; Thu, 20 May 2004 12:59:34 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i4KJxOI1014957; Thu, 20 May 2004 14:59:24 -0500 (CDT) (envelope-from dan) Date: Thu, 20 May 2004 14:59:24 -0500 From: Dan Nelson To: Ulf Zimmermann Message-ID: <20040520195924.GB19455@dan.emsphone.com> References: <20040520194027.GH58545@seven.alameda.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040520194027.GH58545@seven.alameda.net> X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org Subject: Re: Problem with a 5.2.1 system and downloading X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2004 19:59:35 -0000 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 (DF) > 12:26:25.919572 128.125.253.59.80 > 10.1.42.42.49190: S 1889662716:1889662716(0) ack 3565497777 win 5840 (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