Date: Thu, 20 May 2004 14:59:24 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: Ulf Zimmermann <ulf@Alameda.net> Cc: hackers@freebsd.org Subject: Re: Problem with a 5.2.1 system and downloading Message-ID: <20040520195924.GB19455@dan.emsphone.com> In-Reply-To: <20040520194027.GH58545@seven.alameda.net> References: <20040520194027.GH58545@seven.alameda.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040520195924.GB19455>