From owner-freebsd-questions Sun Dec 1 17:07:08 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA10790 for questions-outgoing; Sun, 1 Dec 1996 17:07:08 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA10784 for ; Sun, 1 Dec 1996 17:07:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id RAA04582; Sun, 1 Dec 1996 17:06:50 -0800 (PST) Message-Id: <199612020106.RAA04582@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Rob Taylor cc: freebsd-questions@freebsd.org In-reply-to: Your message of "Sun, 01 Dec 1996 19:33:57 EST." From: David Greenman Reply-To: dg@root.com Date: Sun, 01 Dec 1996 17:06:50 -0800 Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >The software packages that have been tried on the clients (that do not >work are) PC/TCP, Trumpet, Win95 32 bit stack, Trump32, and Netmanage. >All with the same results. > > >tcpdump of a BAD session with a BSD system: > >17:59:35.405378 sys2.2222 > sys1.http: S 103427840:103427840(0) win 2048 (ttl 255, id 415) >17:59:35.406051 sys1.http > sys2.2222: S 3781998081:3781998081(0) ack 103427841 win 17520 (DF) (ttl 250, id 24112) >17:59:35.406952 sys2.2222 > sys1.http: . ack 1 win 2048 (ttl 255, id 416) >17:59:35.420935 sys2.2222 > sys1.http: P 1:284(283) ack 1 win 2048 (DF) (ttl 255, id 417) >17:59:35.426181 sys1.http > sys2.2222: P 1:257(256) ack 284 win 17520 (DF) (ttl 250, id 24113) >17:59:35.429415 sys1.http > sys2.2222: . 257:1717(1460) ack 284 win 17520 (DF) (ttl 250, id 24114) >17:59:35.648940 sys2.2222 > sys1.http: . ack 257 win 1792 (ttl 255, id 418) >17:59:36.831627 sys1.http > sys2.2222: . 257:1717(1460) ack 284 win 17520 (DF) (ttl 250, id 24121) >17:59:39.830035 sys1.http > sys2.2222: . 257:1717(1460) ack 284 win 17520 (DF) (ttl 250, id 24122) > > >TCPDUMP of a good session from the same client (sys2) with a Linux system >(sys3): > >18:00:47.323907 sys2.1111 > sys3.http: S 138686464:138686464(0) win 2048 (ttl 255, id 422) >18:00:47.324715 sys3.http > sys2.1111: S 1140847812:1140847812(0) ack 138686465 win 14335 (ttl 64, id 31299) >18:00:47.325478 sys2.1111 > sys3.http: . ack 1 win 2048 (ttl 255, id 423) >18:00:47.340212 sys2.1111 > sys3.http: P 1:301(300) ack 1 win 2048 (ttl 255, id 424) >18:00:47.341061 sys3.http > sys2.1111: . ack 301 win 14114 (ttl 64, id 31301) >18:00:47.564598 sys3.http > sys2.1111: P 1:320(319) ack 301 win 14335 (ttl 64, id 31307) >18:00:47.567620 sys3.http > sys2.1111: F 320:320(0) ack 301 win 14335 (ttl 64, id 31308) >18:00:47.568328 sys2.1111 > sys3.http: . ack 321 win 1729 (ttl 255, id 425) >18:00:47.571407 sys2.1111 > sys3.http: F 301:301(0) ack 321 win 1729 (ttl 255, id 426) >18:00:47.572211 sys3.http > sys2.1111: . ack 302 win 14334 (ttl 64, id 31309) One thing that is immediately suspicious is the advertized window size from 'sys2'. It offers an mss of 1460, but a window of only 2048? This would prevent any streaming (you want the maximum window be at least twice the mss). I think this is interacting badly with FreeBSD's Path MTU Discovery, but in any case, the above traces clearly indicate that the problem is either on the client side or somewhere in-between. If the clients are connecting via SLIP/PPP (which you suggest), then you may wish to verify proper hardware flow control operation on the serial lines. If this wasn't working then large packets would tend to be dropped just like you are seeing above. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project